Slashdot Mirror
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."
Sounds to me like one of them isn't following the Filesystem Hierarchy Standard...
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Reinvening Autopackage and OpenPKG once again?
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!
Anton Markov
*** Linux - May the source be with you! ***
yup, i agree, even though it is different flavors of ice cream it is still the same product under the hood, which is good for cross-distro application installs which this Smart Package Manager is addressing, i think it is great :^)
"Ability to install software, with all the benefits of dependancy checking, without typing in a root password. Users should be able to get their own up-to-date version of Perl and whatever it depends on, and installing it in their home directory, WITHOUT messing up other users by changing the default perl."
If you're at that level to where you're playing with something for research purposes or getting far beyond the norm, either set up your own damn box or learn how to download the application in a source or raw binary form.
When I was at ASU I used Netscape, running on the SunOS 5.6-based servers, with my X redirection stuff putting the program on the HP Envizex i-Series terminal. It wasn't an IT supported configuration, but if I wanted to use other than their installed "Hot Java" web browser I needed to figure out how to do it myself, so I did. I could have gone over and used a PC or I could have brought my own computer, but it was their equipment, and if I wanted to do something different then I had to do it myself. No handholding.
Do not look into laser with remaining eye.
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...
-- B.
This sig does in fact not have the property it claims not to have.
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.
Humorless sig goes here.
"I'm so tired of the slashdot "well I can do it by going through X steps and compiling source so everyone else can too" crap. The local installation option would be a great great option to have, end of story. Why would you even argue that? Are you trolling?"
Are you a user, or an administrator? If you are a user, then you are subject to the implementation that the administrator chose for that particular computer. It's not your computer . The administrator has to support the users and keep things running. It is not in the administrator's best interest to allow any user to run any version of any utility or program, as it would make easy support impossible. Corporations and organizations build systems with standards in mind to make support feasible-- If you install software on your computer or on your account that the organization doesn't support, the organization resets your stuff back to their default to verify functionality.
build your own goddamn box if you want to play with something not normal, or else figure out how to do it yourself, even if it is the hard way. You were provided with an environment because someone who is held in esteem, both for responsibility and authority, has the power to decide what is on the box. If you circumvent that, you do it at your own peril, and they're not going to make it easy for you to do. End of story.
Do not look into laser with remaining eye.
...Except, of course, YUM originally came from Yellow Dog Linux on the Mac. (Yellowdog Update Manager)
;)
Redhat didn't invent it.
Gentoo doesn't have major versions beyond system profile releases (2004.1, 2004.2, etc). And uh, if a user wants his own version of Perl he can damn well unpack a source .tgz and build it himself with the PREFIX setting available in pretty much every autoconfigure/automake system around these days.
Sorry, my karma just ran over your dogma.
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.
.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.
.... 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.
1) Debian packages are distributed as a
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,
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
Well... that may be what FHS says, but that goes against the tradition that the distros are following, namely:
You're exactly right: the distros leave /usr/local empty because that's what it's there for: a place for your own stuff so that it and the distro's stuff don't get in each other's way.
All's true that is mistrusted
ebuilds are scripts, not packages. Next.
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?
Hello, my name is Robert Lerner, and I pronounce Lernux as "99% cpu"