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."
I give it a week before the infighting starts and the project gets forked six times. Getting a bunch of Linux geeks to agree on a unified ANYTHING is just not going to happen in our lifetimes. Get over it, treat each distro as a diferent OS and get on with your lives.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
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?
If Fedora chooses to include it in the future, I'll give it a try. Until then, however, I think I'll stick to the evil I know (yum), rather than playing musical package managers.
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."
There is no issue with multiple package managers (PM). Each distribution provides a PM which serves it's distribution just fine.
I've tried all the major distributions, and all the major PMA's. Almost all open source software provides binary PM's for the major 3 formats. And for those few exceptions, you send a request to your distribution and they'll get one for you, if you can't compile or build a package yourself.
So, what's the problem here????
Linux == Diversity !-> Confusion
I think this is only an issue with recent Linux converts.
...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 FHS (Filesystem Hierchy Standard) is designed to address this very issue: http://www.pathname.com/fhs/
Unfortunately it isn't specific enough. We need a second set of guidlines to deal with specific classes of software (KDE-based, GNOME-based, pytho n programs, Java programs, etc.). They have some special requirements (CLASS PATHS, ksycoca system, gconf, etc.) that probably need to be addressed. Until then it's up to the distros to decide these issues.
Debian, for example, has a set of "policies" to deal with Java programs, Perl programs, etc: http://www.debian.org/devel/. I think these should be used as a basis for an FHS-like standard.
Anton Markov
*** Linux - May the source be with you! ***
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.
foo.rpm is exactly the problem - eventually you need an app that your distro package manager has never heard of, and its dependancy info isn't useful. A package manager should have support for external RPM files to say "I need package X" and the package manager helpfully chirps "I have package X" and takes care of our poor lonely RPM, without the user having to get all flustered and bothered.
No, we don't.
The reason why we don't is that the problem lies in the concept of GNOME and KDE itself, not the FHS. The pieces of GNOME and KDE need to become interchangable too, just like the package management.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
Comment removed based on user account deletion
Here's a big problem Every important program is packaged many many times... Let's say I make program FooBar. First, I make a source tarbell of FooBar-1.tar.gz. Next, every distribution on the planet will repackage this ... A Debian DEB, and Ubuntu DEB, a Fedora RPM, a Mandrake RPM, an Arch Linux pacman PKG, every other obscure package format..
Next, FooBar-2.tar.gz comes out. All those distros have to repackage FooBar. The developer should be able to make too packages: a source package, and a binary, and be assured that it will work on most distributions. So much repackaging is being wasted, when a standard could arise and the program would only need to be packaged once.
It's worse than that. A major problem would be simply the names of the packages. For example, on Fedora, the pango-* rpms depend on glib2-*. pango-devel would depend on glib2-devel. In Debian, they call the packages pango-dev and glib-2-dev or something. Package manager don't just use lists of provided resources to resolve dependencies; they also use package names.
I haven't read much of the documentation on this project, but the only way it would work would be to implement their own (yet another) package management system and just use rpms debs, etc as sources, eliminating name-based dependencies.
Either way I don't see a huge advantage for existing distributions. I'd prefer a very smart alien (maybe with canonical package names and conversion rules) for converting say from fedora to debian and vice versa.
"...although the typing may scare off most Windows users."
That's exactly the point. If I want to install a Windows version of a piece of software, all I do is surf over to the webpage, download it, and double-click. The rest is a menu-guided GUI walkthrough of the installation process with the "Help" button always within reach at the bottom. Nothing to type; no dependency problems; no obscure flags to look up in man pages. Yes, sometimes it fails and doesn't find a missing DLL or whatever, but out of dual-booting WinXP and Mandrake/SuSE variants, I've encountered far more problems with dependencies than with DLL's.
Installation/removal of software in Linux may be easy for veteran users, but incredibly daunting to newbies. The requirement of typing stuff into a commandline is an absolute no-no when it comes to new users; the Linux software installation system needs to be entirely GUI-based with menu-driven options and help.
Tried and failed?
Tried and died.
The wrapper app simply doesn't know what the imported packages are going to do to each other. At least in a single-source scheme, the manager of the repository can confirm that all packages on their servers play nice with each other. The same can't be said across all package managers and repositories. People will get segfaulting binaries, missing files, versionitis, etc etc etc until utlimately they will reinstall the OS and vow never to touch a metapackage tool again.
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!
Jesus Baron von Christ, geeks, this isn't nuclear fusion science!
Develop an XML layout standard for packages defining everything - names, file sizes, hash values for everything - in other words IDENTIFY EVERYTHING uniguely (and where it ISN'T unique, cross-ref) - then write a package manager.
Do I have to do everything for you morons?
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
But doesn't it often happen that older versions of a package have known security holes? Until now it has been sufficient to package the newer, fixed release and let the systems like apt and yum pick it up. If we have package managers that may deliberately choose an older version, there needs to be good metadata on which older versions of a package are still usable (ie, don't have known or likely exploits).
Indeed this is true of bugs in general, but security is the most worrying example.
-- Ed Avis ed@membled.com
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.
Wow, I am not sure how you got marked informative. It must be becuase you made a long post.
You and the grandparent are talking about two different things. You are talking about security, admins controlling what users do. The grandparent is talking about ease of use for installing things locally. THOSE ARE TWO DIFFERENT THINGS! For example, what if the admin wants to install something locally, and not system wide.
If you want to control what the users of a system are doing, use quotas, use AFS, use dirrectory permissions, use fancy firewall rulesets, etc. None of these things have anything to do with being able to install things in a local dirrectory.
Selling software wont make you money, selling a service will.
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.
which kind of defeats the purpose.
I don't care about the relative benefits (or weaknesses) of whatever installer is on my system (Suse9/rpm - I know. I'm illustrating a point here, okay?). I just want to install and use the damn application.
I don't understand why I should have to have multiple graphics/development libs (nevermind different minor revs) because several different applications each specified it wanted something Completely Different. There have been things that I've tried to install that have had up to 3 or 4 different LEVELS of dependencies that I've had to go chase down: package A needed B - B needed C - C needed D, and it has been a massive pain in the ass. All these different libs have their supporters who say that each one is "better" - but that's "better" for the developer; the end user can't see any difference, and really doesn't care: they just want the pretty pictures on the screen. THIS is why Linux isn't kicking Microsofts ass.
I can compile and install from sources, but Joe Average User can't/won't be bothered - it confuses him too much. Why should he screw around with Linux and the plate of spaghetti that is its libraries and dependencies when he can just download and USE the damn software on a Windows box? If the software he's installing has a newer version of a lib, it just installs it seamlessly; the old version goes bye-bye, and nothing breaks.
I'm slowly switching everything I can over to my Linux box from Windows (some stuff simply isn't available on Linux), and I've been encouraging people to try FOSS software - but only those apps that run on Windows. Why? Because I'm not about to try and convince people that see the computer as a way of actually getting things done to start having to screw around with the lack of standards that Linux suffers.
(Now adjusting Nomex underwear in anticipation of flaming resulting from saying Linux isn't do-all and end-all of OSs)
--- Asking inconvenient questions for over 30 years...
> dpkg -i /tmp/mypackage.deb
.deb from a webpage you are back to manual dependency resolution or the person who hosts the .deb has to build a proper apt-get'able repository and the user has to mess with his sources.list to get it working."
.deb files as if they had been requested by package name so that apt's the dependency resolution would happen.
So, I guess in your hurry to appear all 1337-like, you forgot this part of the parent post:
"While apt-get sure can do it, one can't use apt-get in all situations. If you just pick a
Parent poster wanted apt to be able to deal with single
Uhm, what's the point here?
Ofcourse they can run any code they want, but they run it under their uid and gid. Problems arise only when a user manages to elevate his/her privileges. And that shouldn't happen unless there's a bug.
The problem with all package managers is that they rely in a database of known packages. If you want to install some obscure package that is not in ther databases, you will end up into a package dependency hell.
At the university, I'm taking a course in graphical interfaces and their design. Just to get a feeling of something new, I decided to try Enlightenment. The base packages installed fine in my Suse box, using apt-get, but several epplets came only in source code form. While compiling them, I found that I needed some obscure library or some library that has been deprecated. After some days of dealing with dependences and uncompatible versions of libraries (ImLib, for example) I had to give up. Enlightenment runs fine, but several epplets don't even start.
Until all developers agree to follow a standard for their code to be installed (and I can't foresee this in the near future), there will be no package manager that can get us out of dependency hell.
PENAROL: Seras eterno como el tiempo y floreceras en cada primavera.
I'm not saying this isn't a good idea, but I really can't see the point. Why would you want to fight the package manager this way? Why is it so important to you to put apps in non-standard places?
Installed the Bubblemon yet?