Valve's Linux Development Blog Goes Live

QuoteCorrect me if I'm wrong, but I thought RPM and DEB did not give you the flexibility to decide where to install. Doesn't the package manager put it where it wants to (apart from the user)?

No, the package is more or less like a simple archive you extract to "/".
At least for DEB packages. Not sure about RPM.
This means it's the packager who decides where things go. Of course, distributions might not add certain packages to their official repositories if they don't like the packager's path choices (and/or if it's closed source).

Here's what's in a .deb (simplified list):
-the files to install on the system
-a text file containing a description of the package, its dependencies, version number, etc ("debian/control")
-pre-installation scripts (optional) ("debian/preinst")
-post-installation scripts (optional) ("debian/postinst")
-pre-removal scripts (optional) ("debian/prerm")
-post-removal scripts (optional) ("debian/postrm")

The pre/post-installation/removal scripts are usually just necessary for packages with daemons, etc. Games shouldn't need them. (apart from update-menus or similar in postinst, but this is automatically taken care of by debhelper scripts while building the package if I remember correctly. Haven't packaged for a while, but [URL='https://bitbucket.org/Knitter/puzzlemoppet']need to get back to it soon[/URL]... ;) )

You can easily extract the contents of a .deb with the following commands:
dpkg -x $DEB .
dpkg -e $DEB .

My take on the paths:
-closed source things (or anything self-compiled or from third-party repositories) into /opt (or other non-standard directory in /) or somewhere in /home
-open-source games into /usr/games

RPMs most likely work about the same as Kame posted about DEB files (I know that I can simply open them up in an archive program and manually extract the contents).

This does not change the fact that doing that or what Kame suggested remains a hack and should not be necessary for installing the game on other unsupported distros. I thought we had this situation fixed for us years ago by Loki anyway?

When it comes to how Desura does it, would there be less complaints if Desura made a more active way of making it known that it is up to the user to set the install location (such as it shipping with it's own MojoSetup installer?).

It surprises me that there are people who don't quite grasp that package management systems solve the problems that individual installers create. DEBs and RPMs (and the tools to manage them) exist because there are problems with way that things are done on MacOS and Windows. Sure, there are advantages and disadvantages to each, but embracing what we've been actively trying to escape feels a bit like taking a backwards step.

At the end of the day though, it doesn't make much difference. Unless Valve are going to integrate Steam with local package databases to register individual games and other stuff it installs, Steam will essentially be its own isolated package management system.

That does not answer the question - I fully accept that package managers are an asset and a strength of the platform, but I disagree that they are the best course of action for third party proprietary software for reasons I have already mentioned. I do not consider that to be throwing away a privilege but recognizing the faults and strengths of each approach. Proprietary software is always going to be alien on a free system - as such alien solutions work best for it. That is my take on it at least.

Quoting: "Hamish, post: 5031, member: 6"That does not answer the question - I fully accept that package managers are an asset and a strength of the platform, but I disagree that they are the best course of action for third party proprietary software for reasons I have already mentioned. I do not consider that to be throwing away a privilege but recognizing the faults and strengths of each approach. Proprietary software is always going to be alien on a free system - as such alien solutions work best for it. That is my take on it at least.

Sorry, I thought your questions was rhetorical (and I think that saying that it brings back a problem that we are trying to move past probably indicates what my answer would be anyway) ^_^

I don't really agree with the reasons you mentioned for third party proprietary software. IMO it's better to register software with a package manager so that it can be easily removed and conflicts can be identified than it is to bypass it.

There are other problems with using RPMs and DEBs to distribute closed-source binaries, which I detailed in my articles. Mainly, package managers can't always resolve the dependencies, and even when they can, you have no idea how the dependent library the PM installed was built (and whether the configure options you depend on were built into it in a way that makes it compatible with your program - things like rpath, whether to use shared X11 libs, etc).

In my opinion and experience, unless your source code is open or you're willing to build packages for specific distros/versions, you should really avoid using RPMs and DEBs. A distribution-independent approach that doesn't use package managers is best for distributing a closed-source binary - it's easy to maintain (you have one binary and one "package"/installer to update for patches), and it "just works" on any distro.

I have one installer for each of my games, and I haven't found a distribution yet that my games won't install and run on. That includes both older and newer distributions.

Quoting: "MyGameCompany, post: 5034, member: 68"There are other problems with using RPMs and DEBs to distribute closed-source binaries, which I detailed in my articles. Mainly, package managers can't always resolve the dependencies, and even when they can, you have no idea how the dependent library the PM installed was built (and whether the configure options you depend on were built into it in a way that makes it compatible with your program - things like rpath, whether to use shared X11 libs, etc).

Sure, but is creating a package with bundled libs and no dependency metadata (you still get the benefits of being easily uninstallable, and some level of integration with users' normal methods of installing software) a better or worse solution than a standalone installer? I think this is what the Wolfire installer does. It seems to give the best of both worlds (or at least as much as is possible).

I think some people tend to read into it all too much. I really am with Hamish and Troy on this one, for games just my personal preference is to not have it installed system wide via a .deb - for all the mentioned reasons.

So any clues or indications as to when the next Linux blog post may be?

Quoting: "liamdawe, post: 5039, member: 1"So any clues or indications as to when the next Linux blog post may be?

Nothing that I've seen. That recent blog post by one of the Intel guys might be an indicator that something regarding graphics drivers and optimisations might be forthcoming. This seems to have been the hurdle that was the catalyst for Valve starting to come out about their Linux plans (the call for Linux specialists, inviting Larabel to Valve HQ, the assorted snippets in interviews, and the eventual launch of the Linux dev blog itself), but I suspect that like the other Valve blogs, the frequency of content won't be consistent.

Quoting: "Cheeseness, post: 5036, member: 122"Sure, but is creating a package with bundled libs and no dependency metadata (you still get the benefits of being easily uninstallable, and some level of integration with users' normal methods of installing software) a better or worse solution than a standalone installer? I think this is what the Wolfire installer does. It seems to give the best of both worlds (or at least as much as is possible).

I see where you're coming from. You can certainly build a RPM or DEB that contains your bundled libs. But then you're locked into the install location that the packager chose, like Liam and others have said. I know a lot of Linux gamers like Liam that prefer to have as much control as possible over where things get installed on their systems, particularly proprietary, closed-source apps.

But if you want to support the widest range of distributions possible (which I think is important, since 40% or so of my Linux customers don't use a "major distro" like Ubuntu, Fedora, or SUSE), you would still have to provide something other than a RPM or DEB, because not all distributions support RPM or DEB. That means you now have 3 installers/packages to update & maintain: a RPM, a DEB, and something else (tarball, installer, or whatever). My time is valuable, and I'd much rather have a single solution to maintain that works everywhere.

You could just give people a tarball and expect them to extract and install the game themselves. That gives them the flexibility to install it where they want, and it works on any distro. Many users know how to extract tarballs, and some might even prefer it (don't have to execute an installer, just extract and go!), but it's not very user friendly. And contrary to popular belief not everyone that use Linux is that tech-saavy. My wife, for example =)

The other thing that RPM, DEB, and tarballs don't do for you is install desktop shortcuts, setup links in your system menu (which is located/structured differently on different distros), optionally modify your PATH so you can run it from the command line, etc. A good installer provides so much more than just dumping the files onto the user's system.

I would say the 2 best installers on Linux right now are [URL='http://installbuilder.bitrock.com/']Bitrock[/URL] and [URL='http://icculus.org/mojosetup/']MojoSetup[/URL]. The latter is free, and has been used for dozens of commercial games. Bitrock is expensive (wasn't when I first bought it), but is very powerful and easy to use. Both installers provide you with a single, user-friendly, and easy to maintain package that works on any distro.