Autopackage support (binaries for Linux)

[charlieg]

Perhaps VDrift would be more accessible to Linux users if you guys were to provide an autopackage'd binary:www.autopackage.orgThe benefit of using Autopackage is that you'd have a binary version for people to download and be playing quickly without the intimidating and lengthier process of grabbing the source code, without the need for direct distribution support by distributions or yourselves.Everybody wins! 8)

[thelusiv]

This is an excellent idea! I downloaded my first autopackage (for Inkscape 0.42 and was impressed by the simplicity. The only trouble right now is that the game does not support having data, executables and settings files in different places, so it will have to install to /opt/games/vdrift/ or /usr/local/games/vdrift/ as one directory, rather than spreading things out through the filesystem as is usually done with Linux appliations.

[joevenzon]

sounds cool, someone want to make one?

[thelusiv]

I think I can handle this (unless someone else is keen to), let me look through the docs. Basically I just need to compile it, run ./setup in runtime/ and then package everything in the runtime directory, right?

[joevenzon]

yeah, that's all you need to run the gameyou should probably delete setup and debug for the distribution

[FFuser]

The only trouble right now is that the game does not support having data, executables and settings files in different places, so it will have to install to /opt/games/vdrift/ or /usr/local/games/vdrift/ as one directory, rather than spreading things out through the filesystem as is usually done with Linux appliations.

Is there any chance that changes this soon?? Because I hate the method to startup te game. I think is very simple to change thisRead also: http://autopackage.org/docs/binreloc/Or another method: http://icculus.org/physfs/this should make it more simple to create .deb or .rpm (or other) packages

[charlieg]

Read also: http://autopackage.org/docs/binreloc/Or another method: http://icculus.org/physfs/this should make it more simple to create .deb or .rpm (or other) packages

Don't forget that Ubuntu .deb and Debian .deb don't always work nicely together, and RPM hell is a well documented affair.The whole point of autopackage is that you don't need to create .deb or .rpm packages. Just one format for the VDrift crew to create, and then autopackage does the hard work of supporting the popular (and not so popular) distributions.

[FFuser]

Read also: http://autopackage.org/docs/binreloc/Or another method: http://icculus.org/physfs/this should make it more simple to create .deb or .rpm (or other) packages

Don't forget that Ubuntu .deb and Debian .deb don't always work nicely together, and RPM hell is a well documented affair.The whole point of autopackage is that you don't need to create .deb or .rpm packages. Just one format for the VDrift crew to create, and then autopackage does the hard work of supporting the popular (and not so popular) distributions.

Ok I agree, but some people want only to install native packages and not autopackages (they do't know it or they don't trust it)And I agree that an autopackage for vrift may comeThe only thing that I say is that I would like to see that you can install as most others opensource software for linux (some crossplatform others not) in prefix/bin/vdrift and the data in prefix/data/vdriftOnly If this is achieved you can create native .deb and .rmp packages and autopackagesfrom the site of autopackage"only packages that are relocatable,which means that it must be able to find its data files no matter where the binary is, and data paths must not be hard coded into the binary."

[charlieg]

Ok I agree, but some people want only to install native packages and not autopackages (they do't know it or they don't trust it)

Well that's simply an attitude that needs to change. The logistics of supporting native packages for every distribution are simply unrealistic. It places extra load on the developers of both programs and distributions. Only by encouraging a platform like Autopackage can we (as a community) improve the "Linux" experience beyond that offered by each distribution into a more unified environment where end-user non-core programs can be shared fluidly using tools like Autopackage.

[fizz]

Well that's simply an attitude that needs to change.

Sorry, but that's bollocks. Autopackage isn't the solution. It may be a step in the right direction (I'm not sure of that) but it certainly cannot act as the one and only distribution channel.Unless you bundle everything as static binaries (which you could do with deb/rpm as well if you wanted) it doesn't solve library dependency issues, and beyond that there's stuff like C++ ABI incompatibilties and of course different architectures.The only way to guarantee a working program is to provide native packages. Everything else is just "Try it, you might be lucky..."

[charlieg]

Sorry, but that's bollocks. Autopackage isn't the solution.

Well I did say 'tools like Autopackage' but in your desire to imprecate my point you obviously didn't bother to read to the end of my comment.Autopackage may not be the total solution but it is, as you say, a step in the right direction and attitudes do need to change if further steps are to be taken. People can't be afraid to install something that is not officially packaged with their distribution. And, truth be told, most people (especially those installing games) don't have such a narrow minded attitude. Many games (Enemy Territory for example) are not packaged natively."Try it, you might be lucky" is just ludicrous. You'll find the autopackages out there work just as often as the native packages do. Just people like you write it off without having tried it. And, to be honest, I see plenty of problems with native packages in the forums I frequent (Gentoo &amp; Ubuntu), and have only ever seen 'hey that was easy' comments about autopackaged applications (although since far fewer people use them currently, it's not a fair comparison).Try Inkscape or <a href="http://scourge.sourceforge.net">Scourge<a> as an autopackage. They'll work just fine.Autopackage would make VDrift available to more end-users with very little hassle for either the VDrift developers or distribution developers.

[fizz]

Just people like you write it off without having tried it.

I like to think I know what I'm talking about.

Try Inkscape or <a href="http://scourge.sourceforge.net">Scourge<a> as an autopackage. They'll work just fine.

No, they won't for me. Just like the binary packages of Mozilla and friends don't.

Autopackage would make VDrift available to more end-users with very little hassle for either the VDrift developers or distribution developers.

They may well be true, and I'm not saying that providing autopackages is a bad thing (on the contrary). It's just when people try to take autopackage as a reason to not provide any native packages that it's starting to itch. And you came pretty close...

[charlieg]

It's just when people try to take autopackage as a reason to not provide any native packages that it's starting to itch.

Well there's no point to using autopackage if you provide native packages. Using 1 is easier than providing rpms, debs, ebuilds, and whatever other formats are out there. If an autopackaged app doesn't run on your machine then it's a bug with either Autopackage or the app itself and you should report it as such.The whole point of Autopackage is to make peoples lives easier. The developers only have to provide one solution, the distributions don't need to include and support things directly. To say that developers should provide support for all distributions directly is ludicrous, as is saying distributions should include support for every app out there (games are apps too). There are only so many volunteers and so much volunteer time.What distro are you using such that binary packages have 'no hope' on your machine?

[thelusiv]

While Autopackage is nice, you can't expect everyone to ditch using their distros' regular package managers (like the lovely apt) in favor of it all the time. It is still better to get the package for your distro because it will always work best. For instance, I installed the Inkscape autopackage but some things in the application appear broken - I think this is because I am running Ubuntu Hoary and it has libraries that are older than the versions required by Inksape 0.42. While Autopackage would be a really nice way for us to make binaries easily, it would be ideal to provide .debs and .rpms and even packages for Slackware and other distros as much as we can. For this, however, we have to rely on our users/community because we can't run every distro and package for all of them.As someone mentioned the Autopackage docs want the program not to care where its binaries are versus where its data is, and right now with VDrift that's impossible. Until Joe gets that fixed (he will, eventually), we could just make a tarball binary release or maybe even use a Loki installer (hmmm, that's an interesting thought). What do you guys think?

[fizz]

If an autopackaged app doesn't run on your machine then it's a bug with either Autopackage or the app itself and you should report it as such.

No, that's not necessarily true. There are setups which autopackage simply cannot handle by design, and you either need customized binary packages or build from source (e.g. different architectures). In fact, from what I have seen and read so far, I haven't found anything in autopackage that you couldn't do with apt/rpm as well. Is there?

To say that developers should provide support for all distributions directly is ludicrous, as is saying distributions should include support for every app out there (games are apps too).

That's of course never going to happen, but projects usually directly support only few distributions anyway and rely on the community to provide additional packages. That's fine. As elusiv said, packages specifically tailored for one distribution will always be first choice, and distributions will always make native packages for software they (their users) really care about. At least until some grand unified package manager comes along that combines all the advantages of all packaging systems currently in use.

What distro are you using such that binary packages have 'no hope' on your machine?

The foundation is some old Suse release (5.something, IIRC), with lots of additional stuff. The main issue with most binary packages are the old versions of glibc and gcc used there.