Autopackage support (binaries for Linux)

[charlieg]

SuSE.... 5!?!?! hock:

[fizz]

Yes. After all, that's one of the advantages of running Linux: You don't have to reinstall twice a year.

[charlieg]

Yeah but surely twice a decade wouldn't be so bad.

[fizz]

If I had a reason other than "man, that sounds real ancient" I'd probably do it. But I haven't. Not enough to ditch a nicely customized and configured system anyway.

[charlieg]

I just don't get your point though.You say autopackge isn't a be-all-end-all solution because an autopackaged app would not run on your legacy system. However, if somebody provided an RPM for a recent SuSE, would that run on your system?Why is it that you're discouraging a single autopackage release and mandating multi-distro-package support when it [if I understand your binary issues correctly] just won't affect you anyway since you'll probably always need to compile stuff from source yourself?

[fizz]

My point is that only providing an autopackage and claiming you're done is not enough. My system is just one example of where it doesn't work (albeit a rare one, I'd assume).Admittedly, I'm not too familiar with autopackage but as I mentioned above, so far haven't seen a thing you couldn't do with apt/rpm, too. You just have to create the package accordingly.

[charlieg]

Your system is not a valid example. You run a legacy system. The source code is available for the tiny minority of users like yourself.The premise of autopackage is that you don't need to provide apt/rpm support, just autopackage. For something like VDrift that runs as an end-user app (a leaf application, if you will) and not a library, not being 'integrated' with the local package manager is not an issue, you can just download updates as and when you need them.Also apt/rpm is not a 2-prong solution. A .deb built for Ubuntu will most likely not install on a Debian system, and a .deb built for Debian will not always install on Ubuntu. The scenario is even worse with RPM, and I endured absolute hell a few years back trying to install things on Mandrake - basically anything other than an official Mandrake .rpm would not work and even the official ones would not always work.Autopackage merely attempts to remove all the above pain and reduce the workload for developers (be they contributory or long term).Maybe providing a well-built rpm or deb might be desirable - Inkscape do it in addition to providing an autopackage - but the best way to reach the most users with the least effort is definitely via Autopackage. I just installed the Inkscape autopackage on my system and can not stress enough how effortless it was.

[joevenzon]

Sounds like distributing source code plus an autopackage binary gives the most coverage for the least effort.

[fizz]

For something like VDrift that runs as an end-user app (a leaf application, if you will) and not a library, not being 'integrated' with the local package manager is not an issue, you can just download updates as and when you need them.

I'm pretty sure there is a significant number of users that disagree with you here. Take for example the hordes of Debian users who routinely do an apt-get upgrade or whatever to get all the latest and greatest. How many end-user apps do you have on your system? 50? 100? You want to upgrade all of those separately, from different sources all over the net?

Also apt/rpm is not a 2-prong solution. A .deb built for Ubuntu will most likely not install on a Debian system, and a .deb built for Debian will not always install on Ubuntu. The scenario is even worse with RPM

That's because most rpms (and all debs) are specifically tailored for a single distribution. I maintain that you can easily create generic rpms which are just as "portable" as autopackages.The "issue" autopackage tries to solve is in my eyes philosophical rather than technical, and doing so using a not quite unsubstantial amount of FUD. Whether that is intentional I don't know. I don't want to start a flamefest here, though, so I'll try to wrap this up.Autopackage seems to have some value for users. Fine. To obsolete/supercede package managers like rpm/apt there's still a long way to go, though, and to me it's questionable whether that's a realistic goal at all without doing something like Gentoo does and providing source-based packages (if you don't accept my system as a valid example (which I can understand to some extent, but a good solution should be able to cope with it since the underlying technology hasn't changed substantially) just take one of the PPC distributions).

[charlieg]

joevenzon: exactlyfizz: I'm no longer going to debate this with you. The fact that you debate the use of autopackage for a game and then talk about end users on a network of 50-100 computers basically means you're either insane, in the unique position of running a Free Software games cafe, or quite simply completely off at a tangent and talking about Autopackage as a replacement for managing all packages on a system which I already stated is not what Autopackage is about (leaf apps and all). Also the word "Debian" and the phrase "latest and greatest" quite simply do not belong in the same sentence.

[fizz]

If I may quote myself:

How many end-user apps do you have on your system? 50? 100?

Where did I talk about 50-100 computers? And Debian does have an unstable branch, you know. Does anyone but server types use stable?Apart from that, I guess we have different opinions here. Let's leave it at that.

[charlieg]

Sorry, my mistake. I misread 'end user apps' as just 'end users'. It's been a long day. Again, I apologise.

[charlieg]

In case you guys need more encouragement for an autopackaged release:http://ubuntuforums.org/showthread.php?p=308330

[thelusiv]

Time to bump a really old thread!

Nathan (FFuser) has put autopackage support in SVN. I haven't tested it yet, but you can create an autopackage by doing

Code:

scons autopackage

You will of course need the Autopackage developer tools to do this.

Hopefully this will be able to replace our Linux tarball binary package from here on out. We'll release a .package file in place of it for the next version, please give us some feedback on this.