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."
What happens when Debian .debs and RedHat .rpms want to install to different places? If you installed as one type, would you be then forced into using the same type of archives every time?
For library locations, ld would probably take care of it.. I'm not sure I can think of any off the top of my head but there may be programs that rely on other components being in a certain place, and possibly barfing if they are not.
Delphis
Projects like this create a top-down pressure for packaging formats to standardize, adopt each other's features, and work on new features collaboratively. By having an developer community abstracting package formats and procedures, the package system authors get a comparative peer review, rather than just user feedback. This highlights the benefits and shortcomings of each packaging system in a much more impartial manner than any magazine review or forum discussion.
The GUI part of it really doesn't appeal to me. Lots of my machines are headless, and even with X11 I remote display don't particularly like the idea of installing umpteen X11 toolkits and support libraries on a router/fileserver/webserver just to support package management. It's good to see that they have commandline utilities as well.
Someone had to do it.
If I have one large application requiring version 1.4.8 of a package, and another requrigin 1.6.4 of a package; there should be a way to let me set up
and have whatever necessary packages are under each. Then users can select whatever environment they need through the PATH and LD_LIBRARY_PATH environment variables.What's stopping us from having interchangable package managers? Why can't we just agree on a standard or two (such as putting everything in the same place, and using the same format for the "installed packages" list) so that I could start with RPM, delete it and install Apt, and keep going (or vice versa)? Why can't we make it so that we can choose a package management system the same way we can choose a window manager?
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
The problem is far worse than "waste in redundant libraraies". The real problem is what happens when there is a security hole in a given version of a library. Without central libraries you will have to look at every application to see where its loading shared libraries from.
Somehow I get a yucky-feeling with 'solutions' that are based on wrappering the underlying cruft instead of fixing it. No amount of duck-taping and gui-frontends will make the Linux dependecy and packaging hell really go away, it will just lead to more obscure harder to track down bugs in the end. What I would really prefer to see would be one standard way to package stuff (relocatable and thus not to tied to where exactly it has to be installed, etc.) and how to handle the install. With all the distros around there is however little chance that we will see that any time soon. Only hope currently is really LSB, if lsb conforming rpms get more widespread in the future they might be a small change that packages moves more and more out of the distro and into distro independend lsb-rpms, however this will, if it ever happens take many many years, so I won't hold my breath...
Perhaps not a drag-n-drop in the literal sense of copying all the program files as a single folder. There are many advantages to having executables, libraries, and architecture-independant files in separate places. However, the OSX drag-n-drop system can be used as a metaphor:
.desktop file in the virtual folder that the user can drag onto his/her kmenu, panel, desktop, whatever (.desktop is already a standard).
.desktop file to the trashcan. The package manager is invoked and uninstalls the program.
Create a plugin for Konqueror or Nautilus which, when the user drags a package into the special (possibly virtual) folder automatically executes a 'dpkg -i', 'rpm -i', or whatever other system. If there are dependancies missing, prompt the user to automatically download the missing packages if possible. Optionally use "alien" to convert the packages to the distribution-native format (works like a charm). Finally, create a
To uninstall the program, the user simply drags the
If you don't like the idea of a GNOME- or KDE-specific plugin, create a deamon which will use FAM or something to monitor a special folder, and perform the actions I described above. Clean, simple for the "average joe" and yet fully manageable using existing package tools so if something goes wrong, a more Linux-savy user could fix it.
Anton Markov
*** Linux - May the source be with you! ***
*Giggle* debsums must be a figment of my imagination then... oh and apt-get.org must be too. Of course, with over three times the number of packages as RedHat you don't need to go elsewhere so often, but it is nice to know there's many hundreds of repositories listed. I know most of the sourceforge sites include a .rpm and not a .deb. Could it be because the package is already in debian? It's damn nice to never have to go searching for software.
Gee, I wonder what I have was smoking, that halucination has lasted for years, thanks for enlightening me! Oh, and next time, try getting a clue before you post... Hints #1: Try searching for library versioning if you want to find one of the problems with RPM. #2: yum still uses RPM and so it still has all the old problems with RPM.
If OSX is to be truly ready for the desktop, we need a system like in Linux. Something that is intuitive and simple as looking at a list of available applications of a type, picking the one I want, and clicking a button that says 'install'.
I don't want to have to go to a store and buy CDs or spend a long time searching Google for software that will run on my machine, then download an archive, and finally get the delivery media opened, and drag it somewhere on my hard drive.
Seriously, how is Drag-n-Drop easier than Select-n-Click? Of course, saying "OSX is good" is a safe bet here, because you'll automatically get modded up. I'm not saying OSX is hard, but Linux is not hard in this area either.
I've come for the woman, and your head.
Umm, no. Debian controls their main repository, as does Red Hat. Debian has no control over the many alternative repositories listed at http://www.apt-get.org/, and Red Hat has no say about the contents of http://rpmfind.net/.
Any system that lets users can add unofficial package sources to their management system is subject to dependency hell. RPM-based systems happen to get the lion's share of bad publicity in this department, but any Debian user who experimented with the alternative KDE packages people were sending out before the official packages were available knows that it is every bit as susceptible as Red Hat.
Maybe the main difference is that darn near every program you've ever heard of is available from the official Debian sources, so there's almost never any need to use third-party sources. If Red Hat packaged everything under the sun, then their users would probably use those packages and there would be many fewer problems. I'm not suggesting that Red Hat do this, but I do believe that's the reason for their reputation.
Dewey, what part of this looks like authorities should be involved?
waste? redundant packages? I just installed FireFox on XandrOS, and it took 35MB. The Windows installer is 4MB. I think that Linux is the king of wasteful redundant libraries; it seems that every program wants to install its own version of some arcane widgets. Look at the big, important projects for example:
Openoffice.org 1.1.3:
Linux -- 78246 KB
Windows -- 46100 KB
FireFox 1.0:
Linux -- 8422 KB
Windows -- 4803 KB
AbiWord 2.0.12:
Linux -- 21.16MB
Windows -- 4.8MB
Clearly there's something wrong here. Only OSX binaries are even more gigantic than the Linux ones, and that's only because of the Apple RISC hardware.
just like the humble blood clot... turboporsche@telus.net
Unfortunately it comes at a price. Out of date and broken packages are common, moreso than you might think. I've personally had to deal with this sort of breakage on Debian and Gentoo, and it's very frustrating.
Portage is overly complex. .debs and .rpms and whatever other binary package available, there's be so much less disunity. But as you just demonstrated this aint gonna happen.
no. (same dogmatic statement)
Customizing packages for a specific system is overrated.
for you
In the long run Debian has the best approach.
for you
Portage has too much added complexity.
RPM is too poorly designed.
Hey! Some truth in this post!
If Redhat cut their losses and stopped suffering from not invented here syndrome for just five seconds to realize the Debian packaging format is better, there's be so much less disunity.
And if debianers cut their losses and stopped suffering from not invented here syndrome for just five seconds to realize that from portage ebuilds you could easily generate
Thats life.
PS.: gentoo wasnt thought to be a distro like debian and RH. It was made so people could roll out their own distro based on source (buzzword: metadistro). If someone uses gentoo to make a distro just for himself and compiles everything himself, he should know what hes up to. In the end you cant compare gentoo and debian - they are different tools for different jobs.
For a while there I was trying to use source rpms to get around dependency hell.
The big trouble was in the little things - patches to gcc, or the libraries I had, and occasionally the code that I needed - weren't there.
Case in point - the latest version of Redhat ships with a version of Bison that won't work with g++ 3.4, which also comes with Redhat.
Even bigger - the last version of Mandrake I used (8.2) came with a gcc compiler that couldn't compile the Mandrake flavored kernel with the default options (the ones included by MandrakeSoft).
It was costing hours and hours of time to find out why things weren't working, and I couldn't take it. Sometimes I didn't ever figure out why something wouldn't compile.
This is why I switched to a source-based distro. Other people are working on compiling the stuff on many architectures, in many ways. They usually find bugs having to do with compilation before I do, so I don't have to scour the internet to get out of dependency hell.
Most important of all, this means that any obscure app that I want to install will be more likely to work, because there are fewer compiling related bugs with a distro that has compiling as it's focus.
Mod me down and I will become more powerful than you can possibly imagine!
Out of date yes, broken not in my experience (I run stable). Debian stable is solid as a rock. It's old but solid.
Personally it would be great if debian committed to a yearly release. Any more then that and it would be too much work for my environment.
evil is as evil does
To be fair, recently both Gentoo and Debian got new Wine maintainers after a long period of neglect. Maybe things will get better now. Let's hope so. Unfortunately it doesn't solve the fundamental weaknesses of the system.
Our own software (commercial, Digital Domain's Nuke Compositor) now does approximately this because we were burned too much with it not working on even the slightest difference in machines.
/proc/self/exe and readlink to find it's own name. It takes the directory and adds it to LD_LIBRARY_PATH. It then tacks a '_' onto the end and exec's that program (the name was chosen so ps lists seem to show the right name).
1. Everything is in a single directory. "installation" just puts this entire directory somewhere in the system. We let people choose where. It adds one symbolic link to the path, too (actually the current installer does not even do this link, we let the end user do it).
2. In that direcotory is a tiny c-only program with the name of our program. This is what the link points at and what people think they are running.
3. This program uses
4. That program with the '_' on the end is the actual program. In addition it can assumme argv[0] is a fully-expanded path name. It uses this path to locate data files like configuration information and plugins. And because of LD_LIBRARY_PATH it also searches in it's own directory first for libraries.
5. All libraries people have trouble with get their own version sent by us as part of the install package. This resides in the directory and thus only affects running our program. So far we have had to do libtcl, libtiff, special libraries required by the Intel compiler, our compilation of ILM's EXR library. We have NOT had to do glibc or glibc++ or any of the huge ones, these are actually quite portable.
6. We tell customers that if they are concerned about reusing libraries, to try renaming our copies so they are not found and thus they get the standard ones. This means that a Linux guru can tweak this just as good as any other install, but for the average person it just works!
Honestly I really don't know if this is a good solution, but it works for us quite well. I do think it is annoying that support for this is not more native, especially the inability to search the current directory for libraries, something that Windows does and inspired this solution.