Submitted by For independent software vendors, one of the major problems in supporting GNU/Linux is the variety of package management systems. However, if the Free Standards Group has its way, the next version of the Linux Standard Base will solve that problem by providing an application programming interface that acts as a bridge between the major package systems and software installers. Ian Murdock, CTO of the Free Standards Group, says the solution could be included in the most widely used distributions by early 2008.
This is good news: We will be finally able to say “GNU/Linux” to refer to a certain amount of standard tools and systems and that we will be able to have a centralized point to get apps and libraries.
The problem is: I don’t think that the distro makers really take care to make their products LSB-compliants. Time will tell I guess.
Anyway, I don’t think that the people behind RPM, APT or klik will just say “There’s a new package manager? ’nuff said” and dropt their projects. I, for one, really like APT, so I expect to be able to use it no matter what the LSB says.
Edit: Damn typo, it’s God Bless… How come we can’t change the subject?
Edited 2007-01-19 21:51
The problem is: I don’t think that the distro makers really take care to make their products LSB-compliants. Time will tell I guess.
Anyway, I don’t think that the people behind RPM, APT or klik will just say “There’s a new package manager? ’nuff said” and dropt their projects. I, for one, really like APT, so I expect to be able to use it no matter what the LSB says.
Hi. Did you read the article? If so, I think you missed the bit where it was specifically pointed out that vendors would not accept a new package format, and that the lack of adoption vis-à-vis the LSB has a lot to do with the fact that it specifies RPM as its one and only recommended package format. Instead, the new standard is intended to be a compatibility layer between package managers (in rather the same way as POSIX is a compatibility layer between different vendors’ implementations of Unix and not-Unix), [i]not a new package manager in itself.
You’re right! All Hail Infinite Nothingness!
Wake me up when Linux supports this:
http://en.wikipedia.org/wiki/Bundle_(NEXTSTEP)
One unified desktop
One unified application bundling/package
One unified desktop
One unified application bundling/package
One size fits all.
No, thanks. Next, please!
Really, I like the idea of having a good package management system that can spread across many distributions, but one unified whatever is not the way for linux, at least not for me.
… Wait.
Nope.
– Gilboa
package installers/software updaters should support cid (configuration installataion distribution)
and:
– backup / restore app systemwide settings
– backup / restore app user settings
– backup / restore the app itself (for migration)
– import / export settings to older or newer version of the same app
– automated unattended installs
– and what not else…
When u install Fedora, u have different way of installing software. When u install Ubuntu, u have different. Similarly Gentoo…and many more. lol
As I stated in TFA. What about a protopackage? A packageformat designed specifically to be transformed into a native package by distributors.
With this I don’t mean only something aking to ‘alien’ but rather intended for real integration in their distribution repos. (Even if the alien route should be an option).
This can’t work without distribution co-operation.
From the article:
The recent packaging summit was attended by representatives of the major distributions that use the two main packaging formats, with RPM represented by Red Hat, Mandriva, and Novell, and dpkg by Debian and Ubuntu. Murdock considers this attendance an encouraging sign. “If anything, the distributions are encouraged that we are taking this very simple, pragmatic approach.”
This is a compatibility interface. The distros don’t need to cooperate with each other, they just need to cooperate with the interface. And it will be in their best interest to do so. Much less work for them if they do.
The top #1 problem that IMO stops linux distros from not being able to use the same packages is not so much the packaging format (although it’s also a problem), but the fact that every distro names their packages in a different way.
For example, the X.org packages in ubuntu have a “xserver-xorg” name, but in fedora they have a “xorg” name IIRC. Even if both use the same packaing format, compatibility is not possible: Most packages are named differently, debian-based systems have very weird methods of naming libraries compared with rmp-derived systems. So dependencies will fail when you try to install a package from other distro.
So IMO just adopting a common package format is not going to help. We need that all distros name packages in the same way. And there’s only a viable way to do that: encourage upstream developers to set the name and the dependencies themselves in a file somewhere, ie: encourage upstream developers to take part in the “packaging” work.
LSB RPMs contain third-party apps, not core parts of the distro, so the chance of name overlap is pretty small. An LSB RPM only has one dependency: a virtual package called “lsb” that indicates that the underlying distro is LSB-compatible. Thus, the names of individual packages in the distro (like the X server) don’t matter.
You’re absolutely right… There should be a standard package naming scheme adopted by every LSB compliant distro. This would require the various distros to change, to some extent, their current dependency layout. It’s undoubtedly a tricky process.
But then again, no one is saying the restructuring to be backported to infinity, or even backported at all. And the benefits should would be undoubtedly great. Packages would be basically distribution agnostic. You should be able to just download a package, any package in any format and install it on whatever distro.
eg: You’re using Fedora… So, one fine day you try to install a package, but you don’t have libdeprecated on your repositories. So, now you have to option to fire up aptitude from within yum to search Debian repositories, install the dependency and automagicaly return to yum to finish the package installation, adding both packagaes (the one you where trying to install and libdeprecated) to the system install packages list.
Oh, it’s not just namespaces.
There’s the names of the files (necessary to compare and make sure you have the right thing)
There’s where the files go in the file system (/opt or /usr/bin, or is there an /usr/local/ and is it the same as /opt?, and is /bin the same as /usr/bin or not?)
What kind of package is it? Binary package, source package, install script?
Then there’s what what patches the package has, what options it’s compiled with (having used Gentoo, I realize options CAN make a difference)
What package versions was it compiled against?
What patches/options were those packages compiled with? (As far as I know this may matter a lot less, I doubt too many packages would require optional/nonstandard features of other libraries)
Off the top of my head, those are the various sources of minor incompatability. It’s not insurmountable, but it would potentially require a lot of control information in the package.
Well, that’s just my thoughts. The first three items could probably be dealt with without too much fuss; I’m not sure just how much damage the rest of them would cause. Maybe someone with more experience with Linux packaging could clear this up; I’ve almost exclusively used packages made for my distribution.
Edited 2007-01-19 23:50
This idea is generally useless for source oriented distros like Gentoo/Lunar.
Also Debian based distros having so many packages will not bother such ‘standards’ since their repositories are so big that they do not need to get outside packages.
There is also initiative to make RPM the same [standarised] on all distros that use RPM packages: http://www.rpm.org. This seams really nice idea, but why so late?
Most RPM spec files are less than 100 lines. Gentoo ebuilds are even smaller. I never used apt but I am assuming it is not any more difficult than writing an RPM spec file. Any ISV who spent a lot of man hours developing a product surely can surely write an apt/RPM spec/ebuild file. A lot more difficult problem is that linux distributions let users upgrade system components also. An ISV who assumes that a user has KDE x.y because he has Mandriva version a.b will be surprised to find that user has upgraded to KDE x+1.0. Package managers don’t help in that case.
A much better approach is to develop a tool that can sniff versions of dynamic libraries and any other dependency’s that software may have and test for them explicitly. Going around testing on every distribution
in the planet is really a not a very efficient use of programmer time.
LSB already allows app vendors to package their apps in universally-compatible RPMs. This new API will allow app vendors to ship binary-only installers that do who-knows-what to your system, like in Windows. I simply don’t see how this is an improvement for users or developers. Murdock claims that it is easier for vendors to write installers than to create RPMs, but I don’t understand how this can be true.
Not when you are trying just to get $h|t done! There are times when I get ticked because say I run into a nasty bug in a analyzer while doing a network trace to find a fault in driver code. We can’t afford to fiddle-f*ck around (non-productive work) for hours wasting time because current installers don’t have the latest version (which contains the fix) in its repo. Here is when we need the app updated fast so we can get back to debugging code (productive work).
This is why companies don’t like to support in house Linux development. Far too often simple obstacles like upgrading an analyzer can take forever when it should only take a couple of minutes. Boss comes over to see how that 30 minute bug fix is coming along but you are off spanking your johnson trying to get the analyzer updated just so you can get started.
The nightmare of installing updated software when binaries are not supplied by the distribution truly sucks! And really it sucks even if they do when it is a non-trivial app. I do like installers such as APT as it does ease the pain of fetching dependencies but it only works IF the planets are aligned just right in the repository … this sucks!
Have you ever downloaded KDE in hopes to update to its latest version and tried to build from source? No? How about installing a new Subversion when you have KDevelop on your machine? No? Give it a whirl sometime, as you’ll especially enjoy the apr0 vs apr1 library nightmare.
At the very least I would like to see it solve the dependency hell for user apps but the utimate end game for the new package manager interface needs to allow the UPDATE of any existing installed package with the ease of a click (or enter for you old-schoolers).
If the distribution doesn’t provide you with a binary but the project site does .. no sweat! Just enter the URL of the project’s download site and move on.
thank god! Long needed and now it’s here! Great day!
This will be great for small projects whose basic installation to this point has been distributing source code. I don’t know how they will handle incompatabilities with regard to location of certain configuration files and whatnot. There are standards for these, but rarely are they followed.
As for established distros with well-liked packaging systems, they will likely roll this api support into their tools and continue merrily including their own packages same as always.
I see no downside to this. Still, I wouldn’t be surprised if this didn’t attract enough attention to be really helpful. It requires effort on the part of distro developers who will likely take interest, but where I see it finding success is on small projects without inclusion in the standard set of most distro packages. That’s a harder sell.
Then there’s what what patches the package has, what options it’s compiled with (having used Gentoo, I realize options CAN make a difference)
What package versions was it compiled against?
What patches/options were those packages compiled with? (As far as I know this may matter a lot less, I doubt too many packages would require optional/nonstandard features of other libraries)
All this is covered by the LSB spec. If an application uses only LSB APIs then it will work on all LSB-compliant distros.
Nice rant, but the LSB has already solved that problem, because it allows the original developer to publish binary packages that work on any LSB-compliant distro. So a binary installer published by the original developer is worse than a binary RPM published by the original developer, and the LSB does users a disservice by promoting installers.
Yeah, that was a bit ranty, the comment caught me at a weak point … but!
The point I obviously failed to make is that I (and many others) could care less if they use debs, rpms, on the fly source builds or installers. The key point here is when I select a *binary* package to install/upgrade that should be it. No extra downloading of pkgs, no version lockout because some obscure pkg on my system needs library xyz at version 123. Just upgrade my existing package or install it if the pkg isn’t installed.
<Click-Click>
(progress bar)
/////////////////////////!
message: Application was installed successfully.
<Click>
Done! Off to use the updated pkg.
All I am saying is if I want to monkey with building the app myself I know where to get the source. But if I select a binary pkg to install then one can conclude that I just want it installed and as fast as possible. There’s no need to make every upgrade a lab project on how to effectively search for dependent pkgs not provided by the distributor for the version of Linux you are currently running.
K.I.S.S. is not just for the ignorant, it also serves the impatient.