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."
Combining the weaknesses of five different package managers will surely alleviate "dependency hell."
I'll be over here, playing nethack on my NetBSD box and giggling.
Cretin - a powerful and flexible CD reencoder
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
This tool really points to the fact that Linux distributions in general are all over the map regarding the installation of packages.
I believe that this tool could be VERY useful to an average user, if they can manage to get it installed and configured. From what I've seen, there are many steps to getting this to work.
Linux distributions have a big problem with package installation and management from an end user point of view. They are a MAJOR pain in the ass, even for experienced users like myself.
Hopefully this develops further and provides us with something to aid in distributing Linux over more desktops.
1f u c4n r34d th1s u r34lly n33d t0 g37 l41d Capitalization really works: i helped my uncle jack off a horse
...Debian.
I switched to Debian specifically because of the ease of use with the packaging during the era when RPM still sucked massively and was fragmented between RedHat, SuSE, and Mandrake so badly that they couldn't use each others' RPMs.
If I want to not have dependency-based packages I use Slackware, where I use Slackware's tarred gzips or I download source and compile it. If I want a workstation where I can grab X piece of software easily, then it's Debian.
The only thing that this'll be useful for, for me anyway, is installing software that companies release RPM-only, binary only that don't have Open Source alternatives.
Do not look into laser with remaining eye.
Yeah, the ease of installation of new packages is unbeatable! I just cruised a few websites, and all sorts of stuff was automatically installed.
I'm still compiling!!
Here's a coralized link to the screenshots, too:
deb...rpm...slack What? no Portage? what about my eBuilds?
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.
Please, if someone's making a new package management system; give it the ability to run as a normal user and install in $HOME/bin, and give it the ability to run as a member of the group 'local' and install in /usr/local
I know a lot of people have issues with Gentoo's focus on having the user compile packages that they download using portage, but what would be wrong with simply developing Portage and increasing the availability of binary packages?
Prosperity is only an instrument to be used, not a deity to be worshipped. Calvin Coolidge
What if I want to install Gimp in /opt/gimp instead of where ever the package maintainer decided to put it, how do I tell apt or rpm to change the location? All in all, its much easier to install software in Windows, especially if you'd like to have some control over your file system.
"I use a Mac because I'm just better than you are."
...instead of trying to hack together all the different kinds of package management?
It seems to me that the way to fix this thing is to just pick one and then fix whatever shortcomings it has, instead of combining all the shortcomings of everything (except Portage, apparently).
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
if linux is to be truly ready for the desktop we need a syatem like in OSX. Something that is as intiitive and simple as dragging an icon to the applications folder to install and then dragging it to the trash to uninstall. That should be it. I know there are arguments against this apprach from geeks who talk about the waste in having redundnat libaries, but this is not intenedeed for geeks it is for people who want software to just work.
The war with islam is a war on the beast
The war on terror is a war for peace
Reinvening Autopackage and OpenPKG once again?
I've found a great solution to this problem! They call it Windows!
Great, I'll start using it reaches the stable branch. For now, good luck to all you brave souls out there who run unstable and testing.
By the way, any news on how well it works on ppc and arm? I can't seem to find the source anywhere to test it out. Oh well, guess i'll stick with apt for now.
The Debian packaging system works pretty much perfectly. There are some tiny problems (e.g. the way apt calls dpkg means an inopportune power-cut could leave the system in a worse state than it really should, the equivs package and the meta packages are a tad crude).
Compared to yum, Debian's system works very well. flawlessly. So why doesn't RedHat use it? I rather suspect that is because RedHat didn't invent it, and RedHat has never dropped something they invented over a superior product developed elsewhere.
Debian and the derivative distributions have this sorted perfectly. Even Gentoo has this sorted better than RedHat, even BSD (ports) solves this much better than RedHat.
Yet RedHat continues to use an inferior system, and people continue to use RedHat. For some reason, those people think it is a problem with linux, instead of a problem only present on RPM distributions. Oh well...
Actually, that should read:
users will try to install anything from anywhere.
If you get all your rpms from the rpm repository maintained by your distro, everything is fine. If you try mixing-matching distribution rpms, then you will run into problems. But, keep in mind: distributions do not do this by default. This is the user thinking they can just go around installing rpms built for different systems easily.
The tool that I never see mentioned is a nice and handy little tooll called rpmbuild --rebuild, which you use with .src.rpms. This will enable you to take, say, a .src.rpm for RedHat, and rebuild an rpm on a Mandrake system, and install it easily.
Often people touting dependency hell have never actually tried to go beyond the basic .i586.rpm available from different distros.
Comment removed based on user account deletion
I spent several hours last night fighting with an IMAP server package on NLD (which is SuSe, and therefore RPM, based). In order to install the package, I first needed to install an authentication library, no big deal, I can build an RPM from source, right?
Well, here's the catch, some of the dependencies defined in the spec file distributed with the source looked for dependencies with RedHat names. I already had the freaking packages installed, but the package name registered in the RPM database was *ONE* character different, and the dependency check would fail as a result. So I got to spend time hacking away at spec files til the blasted thing finally gave in.
It's things like this that make me believe that the sooner we can move to a standardized base, the better off we'll be. Linux lags so far behind Windows, let alone OS X and its drag and drop installs, in this regard that it's not even funny.
With NOBODY to hold my hands. Because the life of the geek is a lonely life.
www.clarke.ca
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.
You're describing a problem with package maintainers specifying needlessly specific dependencies from their own system (/usr/lib/libfoo.2.6.4-a1.so.1.2 instead of /usr/lib/libfoo.so, or even better, libfoo). It's not the fault of the Package Management system. If lonewolf maintainers would build against standardised dependency names, then yum, up2date, apt, urpmi, yast, and anything else would be given a sensible list of dependencies which it can resolve and the world would live in harmony.
I think I like the OS X approach better; it is just so much simpler. The application is self-contained in a directory with an .app extension and a special structure. The OS recognises the structure and knows what to do when you double-click the icon.
That's all.
Installation means dragging the icon (mv'ing the directory) to your hard drive. Want different versions? Want to uninstall? Just get rid of the directory. No problem, just rename the old version.
Drag and drop isn't the point. The point here is that there is conceptual simplicity. No dumbing things down for the "average joe" because there is no need to. Less chance of anything going around that you'd need to find a Linux-savvy user to fix.
We should strive not to dumb things down, but to make things inherently easy to use!
If you circumvent that, you do it at your own peril, and they're not going to make it easy for you to do.
/usr/local/bin or /usr/local/lib.
That's his exact point. A package management utility should allow people to easily install shit without circumventing anything, and without requiring root access. No one is discussing circumvention, or doing anything the admin doesn't want, and you are being an asshole.
I can install mozilla in ~/bin. I can install all of mozilla's dependencies in ~/lib. This is totally acceptable by anyone's standards, so long as I don't exceed storage or cpu resource limitations. An excellent package manager should do this for me, and not require that I have access to
Why is this objectionable in any way? Are you trolling?
There are no trails. There are no trees out here.
Or if Linux could instead accept something like NEXSTEP/Mac OS X Frameworks: a properly versioned system of dynamic libraries, no more symlinks, unfound symbols, linking errors because of path, LD_PATH or what have you. Just clean pre-binding, shared object discovery at runtime, and no more DLL hell.
Then just see how easy it will be to make packages work together.
Why would you bother with clicking and dragging when you can simply edit the compile script to your liking, then ./configure with whatever tags suit you, make, make install, go through the output to figure out the dependency errors, download and install the necessary libs, re-edit your compile script, ./configure, make, make install again? That should really be all you need unless you're doing something fancy.