“Curtis Knight, Isak Savo, and Taj Morton are the lead maintainers and developers of autopackage, a set of tools designed to let developers build and distribute distribution-neutral installation packages. In this interview, they share their vision of the project and where Linux packaging in general is going.”
I don’t see this as the better solution, Linux should have a standar package format by now.
Edited 2008-01-17 23:30 UTC
The only advantage of Autopackage is for people who don’t have access to the Internet. They can go to a cybercafe, grab themselves a few packages on a USB flash key, and when they arrive at home, they can copy the packages and install them without the need for a connection to the Internet. This would be a lot more painful with RPMs for instance.
Otherwise, installing a package is simple already, just launch your favorite package manager, type the name of your application, click “Install”, wait 5 minutes and you’re done.
OT: I have no idea why your post was rated -1. It’s not off topic, insulting, or spam. Maybe people just don’t like you?
Anyway, I boosted it up to “0”. I think there may be some bugs to work out in the new OSNews rating system…
1) His trust levels are low, as such his comments start lower.
2) Don’t complain about the rating system in the comments. It’s off topic.
I have done too much evil to OSN expressing myself harshly. I have always been too frank. I haven’t always agreed with everybody. I have always spoken out for the little guy. I have always fought übergeeks mentality. OSN isn’t the right place to do so.
Today is a good day for OSN. This is my last comment. I mean it. I’m going to change my password into a series of characters that I can’t remember and I’m going to log out for good. You won’t see any more comments from Joe User. I know Eugenia won’t miss me either.
Good bye.
ps aux | grep joeuser | grep -v grep | awk ‘{print $2}’ | xargs -t kill $2
That’s if the software you want is in your distro’s repository, which isn’t always the case. For example, when I last used Mepis and Ubuntu (several releases ago), XnView debs were hard to find. And mplayerplug-in packages were out of date for a long while.
I love these replies. They are such a dead end. It’s simply not possible to put all applications out there in the repository of your favorite package manager. Sometimes because the software is commercial and sometimes just because there’s no packager for it.
Most of the time you end up with either the source code with ridiculous build and/or issue solving times, or a flaky package with a custom solution.
Kind of ironic. People praise OSS not only for freedom, but als for standards. Well, having the need to install your required software from three different package managers, a custom installer solution and from source, surely ain’t no standard at all.
Five minutes? Simple? Quick? Pah, if you’re lucky and use your average OSS software only: yes. When you’ve got different needs than tweaking settings, watching windows burn (yes, pun intended), programming or browsing the web, you’re usually f–ked.
Most of the time you end up with either the source code with ridiculous build and/or issue solving times, or a flaky package with a custom solution.
I do compile stuff from sources every now and then and it is usually just “./configure –prefix=/usr;make;make install”..Not really that hard
On a binary distro you have to install gcc and the corresponding -dev packages but even that doesn’t really take long.
Kind of ironic. People praise OSS not only for freedom, but als for standards. Well, having the need to install your required software from three different package managers, a custom installer solution and from source, surely ain’t no standard at all.
The only universal method of distributing an app is sources.. I do admit it’s a bit awkward, especially for the less experienced, but it can’t be helped. Distros differ too much from one another. And there will never be only one distro left which everyone would use.
That’s fine for geeks, but doesn’t work well for the average computer user. Remember – most computer users are not that smart with respect to the computer. (They may be brilliant in something else though.) For example, how many grandmothers would be able to figure that out? Or even understand it? Or even want to try? True – probably more now than 10 years ago, but the number if probably pretty low.
Distribution by source only really works for F/OSS software. There are a lot of companies that develop software and focus on Windows and Mac, but leave Linux out. Why? Because they don’t have any easy, universal, and simple way for people to install their software.
This is where solutions like Autopackage come in. Autopackage works with the local systems’s package manager (apt, pkgtool, rpm, etc.) to register it with the system, and also provides some final linking steps so that things like libc don’t need to be packaged all the time.
Honestly, I think we need to get LSB updated to have Autopackage or something similar mandated – if not replacing RPM at least along side RPM. This would provide a great deal of opportunity for commercial software vendors to develop for Linux and really open the market.
FYI – I also don’t see the Linux Desktop market growing very fast without something like Autopackage becoming part of the LSB either simply because of how much it would enable commercial software (games, applications, etc.) to be able to target Linux easily too – and RPMs are not the answer.
I don’t think the LSB needs to include installation methods as well.
RPM is in there for historic reasons, an attempt to make “standard” packages some kind installer, i.e. using the LSB RPM as an installer additionally to the package manager the distribution is using for its packages.
As I said in my other posting, it is technically possible to do this, i.e. use a package system for the role of the installer, but it is not a wise choice, since the base requirements are different.
The parts of the LSB which are important for the ISVs are mainly the specifications which libraries exists with which ABI.
As with other platforms they can leave the actual installation to installers and they have plenty of options there on Linux as well.
This is the system they are used to so trying to put them into package boundaries is very unlikely going to work.
IHMO, the idea to have ISVs install their software, packages by them, through the systems package is flawed.
It is either letting the distributor handle the packaging or installing through an installer.
Both work very well, can be used in parallel, but forcibly combining them in one “übersolution” does not.
Edited 2008-01-18 17:52 UTC
Otherwise, installing a package is simple already, just launch your favorite package manager, type the name of your application, click “Install”, wait 5 minutes and you’re done.
That is, provided you have the app (or the version of it that you need) in the repository.
Also, packaging for multiple distribution means work duplication, and probability of introducing packaging-related bugs is higher.
Moreover, with a single binary package, you have more chances to get a specific bug fixed upstream rather than going through the distro bugzilla route.
This is a totally orthogonal domain.
Package systems and installers have different goals and while it is possible to let one do the others job as well, it is better to let each one handle its own job.
A package system is about shared maintenance, e.g. a bug fix in a library being fixed once, packaged once and update once.
An installer is about independence, being self sufficient so to speak.
Basically all platforms enlist both concepts but probably have other ranges of responsibility associated with each.
Lets use Windows as a comparison: the package system only handles operating system components and a bit of other software (e.g. default Windows games) and lets the installers do the rest.
Linux increases the range of responsibility of the package system to a larger set of software, the applications available through the vendor’s repository.
However there is still room and need for the installer, not only for proprietary application vendors who do not want or cannot participate shared maintenance, but also for free software vendors who anticipate that the better independence e.g. allows them to deliver new features faster or retain functionality longer or simply don’t want to rely on a third party for some of the maintenance work.
It does. Read the LSB spec. RPM is that official format
“It does. Read the LSB spec. RPM is that official format”
Then the LSB sucks. Some of the most popular distros don’t use rpm, none of the ones I would recommend do. Thank god.
No, the Linux distributions suck. Instead of promoting unity and putting users first, they decided their way was better. If they had banded together, deb could be the official format instead. But who cares about standards, right?
“No, the Linux distributions suck. Instead of promoting unity and putting users first, they decided their way was better. If they had banded together, deb could be the official format instead. But who cares about standards, right?”
Choosing APT and .debs are putting their users first. I use Debian at home, RHEL at work, and APT is faster, and better at resolving dependencies then rpm or yum. And when you consider the fact that dpkg (the underlying technology for APT) came out in 1994, and RedHat was still using RPP, then the APT system predates rpms, and it would be a real disservice to their community if the .deb distros changed package managment tools just to satisfy the LSB. The LSB is what standardized on rpm, not Debian, or Ubuntu, or anybody else.
That is an opinion. Not a fact.
You apparently didn’t read the last portion of my reply where I said: “If they had banded together, deb could be the official format instead.”
Why? Who said they would have picked APT? That’s an opinion, not a fact
Logically, if APT is as good as you say, and so many use it, then it would be chosen. Right?
Ahem.
If that was always the case, we’d all be using Linux or OS X, perhaps even OS2. USB wouldn’t exist, and we’d be using firewire. The best technology doesn’t always become a standard, or even get chosen by the market as a defacto standard.
If that was always the case, we’d all be using Linux or OS X, perhaps even OS2. USB wouldn’t exist, and we’d be using firewire. The best technology doesn’t always become a standard, or even get chosen by the market as a defacto standard. [/q]
Or maybe it isn’t the best technology…
You realize that apt was ported to work with rpms, right? Dependency resolution is the job of the package manager, not the package format.
At any rate, the strength of .deb lies in the packaging guidelines for Debian. .deb was never designed to mix packages from different distributions together, in fact it often falls apart when you try and mix packages from debian derivatives.
RPM, on the other hand, uses file-based dependencies, which makes it a better solution for varying distributions. If an application needs to a library file xyz.so from KDE, it lists that library as a dependency. Whether that library is include in package kde3libs in RH or package kdelibs3 in SUSE doesn’t matter, the depenency will be fulfilled because the package manager will know how to locate it.
This granularity is what adds to the overhead of RPM-based systems, admittedly, but it offers better flexibility for packaging.
The only way .deb would make sense as a universal package format would be if the LSB standardized on package naming conventions and which packages can be expected to contain which libraries. That would never happen; the drawback to .deb is that it was never designed to work beyond Debian.
If you’re complaining about package dependency resolution on RHEL compared to Debian, then you should be opening a ticket with Red Hat because clearly there is something wrong with the way the packages are built. There is absolutely no reason for rpm dependency resolution issues within a distro’s own packages except for human error, which does happen with .deb packages as well.
RPM certainly isn’t without faults, but it’s a better universal solution for package management than DEB is. Personal preferences are no basis for standards.
And for the record, Debian was part of the LSB committee. They were simply the only ones at the table using .deb, which is for all intents and purposes a distro-specific package format, not a universal one. It would have no place in an official standard.
This whole Deb vs rpm debate started in response to something else all together. It’s pretty offtopic, and I really don’t care. I prefer .deb based distros, that’s my choice. If you disagree, that’s fine. I think the fact that APT has been ported to rpm based systems says something, but also offtopic.
It’s just not important enough to keep this going.
The APT thing doesn’t work against RPM. APT also exists for RPM you know and has done so for years.
The whole .deb vs. .rpm is moot and has been so for several years.’
*buntu use .deb with Synaptic (frontend for APT) – Fedora uses .rpm with Synaptic (frontend for APT).
However, I fail to see how this is different than .exe .bat .msi etc. installers on Windows (except Windows lack a proper centralized package management – one can install .rpm/.deb by double clicking on a downloaded package).
Yes, and a fat lot of good it’s done us all. Most distributions still don’t use RPM, and just because you have two distributions using RPMs it doesn’t mean that a single RPM package will work for both. The LSB at times reads like the whole early nineties Unix ‘This is the standard’ thing – and then people went of and used something else regardless.
Yeah, like that whole standard for TCP/IP, HTTP, POP, MIME, etc. Standards from 10-30 years ago are so useless.
Are you really that much of an idiot, or did you not understand why those ‘standards’ became standards? TCP/IP was widely used because it was the best option, and it broke free of all the vendors’ proprietary networking protocols. HTTP, POP etc. were used simply because they provided something new (internet access and e-mail) that hadn’t been available before.
In essence, people used them because they were the best and provided them with something new.
RPM? I’m afraid no one is going to use it because a committee said so. It isn’t unique, doesn’t provide anything new that people just want to use and is re-inventing age-old concepts. That’s what design-by-committees don’t get. They, and you it seems, still believes that if you label something a standard then people will just use it.
The same can be said for debian distributions. .deb packages don’t magically work on all debian derivatives either.
Yer, and? Does that justify sticking RPM within LSB and saying “Though wilt use this”? Whatever is in the LSB, referring to my comment above, has to do something different, better and solve some fundamental software installation problem (God alone knows Linux distros have many) that will make people want to use it. As it stands, RPM just isn’t it, and telling everyone it’s a standard, default etc. will make no difference.
The sad truth is that Linux distributions just do not see the need for people to install third-party applications, or for developers to create their own installers so it’s easy and straightforward to configure their software.
You’re simply not going to get everything in a gigantic package repository, as anyone who has tried to install something up to date will know. It might be stable, and it might be exactly what you want, but Linux distributions make it as difficult to install anything outside of their own package repositories as possible. You might be lucky enough to get backports, but then, you have to go out and find them.
Then you have the whole political thing, which I’ve never understood. Many distributor developers rail against anything that they perceive to be compromising the integrity of their own little package repositories. Debian’s position on Ruby Gems is a classic little bit of theatre. It doesn’t matter that Gems is only a little installation system purely within the domain of Ruby, if it treads on their toes the Debian people don’t want anything to do with it.
If a distro wants to get ahead then this is one area in which they can do it.