If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

2) RPM-- I know people get really up in arms about RPM vs Deb but my personal vote goes to RPM because Enterprise already does RPM (RHEL + CentOS) and you can do delta packages. Maybe delta's are more an issue of apt-get vs yum but under Debian you download the whole new package, under Fedora you only get the binary difference. I like delta's.

I realize because of Ubuntu that .deb has kind of become 'the standard' for desktop but really it'll probably come down to punching match between Red Hat and Canonical then between RPM and Deb since Ubuntu has desktop and Red Hat has enterprise unless by some miracle they can come together and settle on a package format and package manager (again..yum..please. yum search is so much saner than apt-cache search).

For libraries either run statics, supply them yourself, or have distros package all versions of a libraries wherein there was an ABI break so that we can just run stuff across the board as long as its ABI compatibile (obviously if there was an API break then its an ABI break too) this way when you install the package it just pulls in the library dependencies it needs from the repos

disclaimer: no, I'm not one of those "We need a stable kernel interface! Backwards compatibilty for 20years!" guys, or even release to release. I actually have no problem breaking BC, but if they are going to mandate specific library versions then thats probably the best way to do it.

Comment

I am really courious on how Valve is going to pull it off, distribution wise, eg. package manager or self-conatined installer. I usually prefer the .sh installers because I mostly find myself installing games on one user as oposed to system-wide.

That being said, I do understand the guys from GOG's concern, supporting such a huge userbase of distros is in no way a trivial task.

Comment

Or they could have some kind of client that installs games in its own folder, like ~/Games(or company name whatever) or /games. So it just needs to download a binary package of their favorite format and unpack. Library issue and breakage you say? Just pack the libraries you compiled with in your package, and it works in ANY Linux, voila. Correct me if I'm wrong, but wouldn't the last part solve breakage for programs?
I've often read about it, but whatever binary I downloaded tended to work on multiple Ubuntu versions, Arch, Chakra, Fedora, etc. At least when it had it's needed libraries with it. So I thought BS whenever I read about such stuff ..

Comment

I just bought 4 games in a sale on GOG today to run with wine/custom engines (the HoMM series), it's nice to know I haven't misplaced my money. Who knows, maybe someday those will run properly on linux too.

I know this discussion is going to end up here anyway so im just trying to be ahead of the curve... standardization of packages on the linux desktop?

Format: RPM
Frontend: PackageKit

Justification:
<snip>

This is not the main issue. Actually you talk about the main issue: common system libraries that sometimes have to change their ABI (image libs, sound, X, ...).

I think once you solve that, you can talk about a common packaging format. Otherwise, it really doesn't matter. You can already use alien to go from rpm to deb, and vice-versa, so if a package is done properly, you can convert, and it will work.

Many times it won't work, exactly because of those library dependencies. So mucking around with the format of the packages and even the frontend application won't solve the issue.

Comment

Just wanted to add: think of deb and rpm and most other formats as zip/rar/tar.bz2. The issue is not the container, it's what you put in there, and how you get it to run across distros.

Spot on, my thoughts exactly. Many of the older games are already bundled with DOSBox. Should they do that for Linux even though most distros have their own package for it? Should it be 32-bit? 64-bit? Static or bundled/unbundled shared libraries? PulseAudio support or plain ALSA? Do they provide GUI and/or console installers? Does the GUI installer use GTK+/Qt/whatever? Repeat all that again for newer games under Wine but also consider that Wine tends to suffer from regressions so the latest version may not always be best.

Personally I hate bundling and think they're trying too hard. For the DOS games at least, the current downloads suit me fine. Until quite recently, the experience was very painful because they use the InnoSetup format, which was impossible to extract without Wine until InnoExtract came along. I started packaging some of the games with native Linux engines for Gentoo a while back and another user has been carrying that forward lately. It would be nice if distros could also package at least the non-native DOS games, which run very reliably under DOSBox. I can understand their reluctance to deal with Windows games but even those could potentially be put in a Gentoo overlay with a big fat warning. It's something I've thought about for some time but haven't had the motivation for.

Comment

I started a small company with the intent of packaging and testing commercial/closed source or even open source applications for the most wanted distributions. I even started to make an automated build/test system (sort of Jenkins-like but more for testing than just building), but whenever I contacted a potential customer (Humble Bundle, some indie game developers and others) their reaction was always "very interesting and we need it but it's too expensive for us for the Linux platform atm.".

Go figure... well needless to say the company is dead now and I'm not resurrecting it. I wouldn't be surprised if I offered the same to GOG they would reply the same way as well. They all think it should be done for free or in other words "why pay for Linux testing and integration when Windblows and Mac are 'free'"

Comment

I am really courious on how Valve is going to pull it off, distribution wise, eg. package manager or self-conatined installer. I usually prefer the .sh installers because I mostly find myself installing games on one user as oposed to system-wide.

That being said, I do understand the guys from GOG's concern, supporting such a huge userbase of distros is in no way a trivial task.

Or they could have some kind of client that installs games in its own folder, like ~/Games(or company name whatever) or /games. So it just needs to download a binary package of their favorite format and unpack. Library issue and breakage you say? Just pack the libraries you compiled with in your package, and it works in ANY Linux, voila. Correct me if I'm wrong, but wouldn't the last part solve breakage for programs?
I've often read about it, but whatever binary I downloaded tended to work on multiple Ubuntu versions, Arch, Chakra, Fedora, etc. At least when it had it's needed libraries with it. So I thought BS whenever I read about such stuff ..

and i don't prefer ".sh installers" and "installing games on one user". i even have 'noexec' on my /home and no desire for any binaries there, thank you very much. so, "I thought BS whenever I read about such stuff".
...BUT having their own game-launcing package managers (like Steam), that manage a particular subset of the file-system (like /opt/<manager-name>) is not a bad idea at all, actually. especially since there is not a lot of steps between game "store" app, and various multimedia "store" app, which those eventually will become.