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."
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.
deb...rpm...slack What? no Portage? what about my eBuilds?
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
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.
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.