Unifying Linux Package Management

Job Diogenes Ribeiro Borges writes "The Smart Package Manager is an intelligent tool that works on the 'dependency hell' of software upgrading and installation on linux. Works with all major distributions (APT, APT-RPM, YUM, URPMI, etc), supporting multiple sources and technologies concurrently. Yes, you could install from multiple sources, from deb, rpm, tgz at same time! Smart Package Manager is being developed by Conectiva and is the tool that makes the Magic of CrossPlatform package management, behind the recently announced 'Four Linux Vendors Agree On An LSB Implementation.' You can get screenshots here (portuguese texts) and a README here."

Comments

Re:What happens when they don't agree?

[mrchaotica]

Sounds to me like one of them isn't following the Filesystem Hierarchy Standard...

Reinventing

[paugq]

Reinvening Autopackage and OpenPKG once again?

Re:You're going to hate this but...

[space_man51]

That's because they don't have a "Package Management System". They have an "Installer", which "installs" the program onto the system. From there on, you are on your own (good luck removing the program later).

Oh, and what do you think a "Missing xxxx.dll. Aborting." message is? It's a lack of dependancies!

Re:Portage

[Balinares]

Let me rephrase your question:

What would be wrong with simply developing any specific package management system?

Portage is great, alright -- in particular, the possibility to pick your own choice of dependencies (like, ALSA but no OSS, SDL backend but no svgalib...) and have it respected all through the system, is the greatest thing since sliced bread.

And with binary packages, you lose that possibility. Unless you provide as many packages as there are possible choices. Good luck.

Besides, if you mix binary packages from different sources, you also get the problem of programs compiled against different specs/glibc version than the libs they end up linking to on your system. The good old third-party RPM recipe for crash.

It's an old problem, and there still isn't any clear solution in sight. Even in distros with the most painstakingly maintained package repository, like Debian, you'll generally need to recompile software to your own needs (support this or that DB backend that your company requires, add ACL support, etc...).

There are only two paths toward solving this class of issues, to my (non exhaustive -> grain of salt, please) knowledge:

1) Somehow provide an API, perhaps glibc-wise, that will allow to disable the relevant paths of code at runtime if the required library runtime is not available. Yeah, I know about dlopen. No, that's not workable. dlopen needs to be designed around. What we'd need would be something as easily managed as #define _HAVE_SDL, only at runtime. There is no way to ensure its adoption if you don't make it as efficient to use as possible.

2) Agree on a common set of libraries -- think DirectX, only system-wide, not just for games -- and have programs 1) depend on the required version of that LinuX set of libs, and 2) ship with what libs they need that aren't in it. The good thing is, if you define a given LinuX version as, simply, an empty package depending on a set of libraries with precise versions and compilation options, each distro can use its own package management to handle it. This is not without drawbacks, though. How do you handle security updates? (Ebuild-like revisions might work, admittedly...) And, just how BIG would any given LinuX-x.y be?

We may never see a smoothly working universal Linux dependency management system, I realize. Still, it's good that there are still possibilities to think of. Perhaps, someday...

gentoo, et al.

[mizhi]

I've had some nightmares with portage using gentoo before. Keep in mind, it's my distribution of choice, but that doesn't mean that portage is not without its problems.

RPM does suck (/flamebait) but don't fool yourself into thinking that the other package systems are problem free.

Re:Politics

[lakeland]

The best way to answer this is to encourage you to go out and make a couple of both. But, I'll try to give you a couple starting points off the top of my head. Again, you really need to try them to see.

1) Debian packages are distributed as a .orig and a .diff. The .orig should match the upstream md5sum, and the .diff is usually small enough to read easily. This has a number of benefits: For the paranoid it is much easier to see that debian is not introducting any security holes (if you know upstream are safe, then verifying the debian package is trivial). And in debugging it is easier to determine if a bug is in a debian extension or in upstream.

2) (Technically, not an advantage to the deb format, more the tools). Debian packages obtain their version depends automatically, making the depends much more reliable. All debian packages are built by the autobuilders which start with a minimal install of debian and then only install the packages in the depends, thereby ensuring that the package will install and run with the depends that have been listed.

3) Debian packages have better support for depends, build-depends, conflicts, suggests, recommends, replaces, .... RPM has some of those but it doesn't have them all. As a package maintainer, having them all just makes life easy. Incidentially, this is an area gentoo goes better than Debian, but I digress.

4) RPM does version numbering based on either packages or files, and the automated tools make it easier to do version numbering based on files. This means that unless the package maker is skillful it is easy to end up in a RedHat equivilant of DLL hell. Generally the guys at redhat are smart enough to work around this deficiency in the file format, but it is still a problem.

5) Debian packages have a very nice handling of preinst, postinst, prerm, postrm. Having all those different scripts makes it easy for the package maintainer to do things elegantly where the RPM package maintaner has to do the same job as a bit of a hack. This is pretty much only noticed by users when something goes wrong.

6) Configuration options are handled by a standard mechanism and answers stored in a database. This all makes reconfiguration, reinstallation, transferring installation, etc. much easier. Similarly, when you upgrade, you are shown diffs of your configuration files and (new feature) can even have your modifications automatically added to the new version. RPM doesn't bother with this very much at all.

7) Virtual packages are not handled well by either format, but I would say the debian version is slightly better (because of Provides:).

8) Debian pacakges are built using standard tools (ar, tar, gzip). This means they can be created, extracted and the like on a non debian system. RPMs can be extracted using rpm2cpio, but I wouldn't like trying to create a rpm on a non redhat machine.

9) Logging of all actions is supported by deb, and you can have the logs emailed, etc. This is pretty pointless if you're just managing one machine, but with many sysadmins and many machines it is very nice. On second thought, this is more a tool benefit than a file-format benefit, so I better stop here...

Most of the deficencies in RPM can be masked by a skillful maintainer. If you build a good RPM it can be about as good as a good DEB. The key difference then is that building good RPMs is more work than building good DEBs because the debian file format contains the control structure that makes doing the job easy while the RPM format only contains the control structure that makes the job possible.

Most often the deficincies manifest themselves in userspace when you're using 3rd party RPMs. Because the package manager was not as experienced at making packages as a RH employee, the RPMs don't deal with version conflicts, depends and the like so elegantly. Contrast this with 3rd party DEBs and the file format m

Re:Politics

[moZer]

Hrm, I think some of the information about RPM needs to be clarified.

1) RPMs are distributed as upstream source + any number of patches. That's equivalent.

2) RPM calculates dependencies by looking at what libraries are linked to by any of the files in that package. You never specify a dependency on say, "gtk2", that is done by RPM. Except for the case when a program calls an external binary, such as k3b depends on cdrecord.

3) RPM has everything but suggests and recommends.

4) Not sure what you mean there, but I think it's about packaging different versions of the same library to be installed in parallell, like qt-2.3.1-1 and qt3-3.1.1-1? Debian does that too, I don't know what's automated in that process however.

5) RPM has pre, post, preun and postun scriptlets. Those are simply short shell scripts that are run at install/uninstall. How is that any different?

6) RPM has a policy of never asking any questions during install. IIRC you can set the ask-questions-level to "never" in Debian, which would be equivalent. Nice thing to have though.

7) RPM has Provides:

8) Well...you need rpm, rpm-build and popt. Maybe not as standard as ar/tar/gz, but by no means impossible.

9) Logging is possible on the dependency manager level (yum/apt/up2date etc). I don't see why you'd need additional logging at the lower package manager level.

That should make the list a bit shorter. I'd agree that DEBs are a bit more feature-rich, mainly because of the configuration abilities and suggests/recommends stuff, but the difference is not that big.

The main advantage of Debian packages is not in the file format, but in the fact that there are basically no 3:rd party packages. They are all in (one of ) the main Debian repository(-ies), and are therefore compatible. What do you think would happen if there were to appear 10 dpkg-based distros, with package names and packaging guidelines each slightly different from each other, and from Debian?