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."

Comments

Oh, dandy

[krog]

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.

Re:Oh, dandy

[whyne]

I don't understand all this fuss is about. cvsup -g -L 2 /usr/ports-supfile cd /usr/ports/xxx/xxx make install clean there is always pkg_add -r xxx.xxx.xxx or in a pinch : portsdb -Uu portversion -l "" portupgrade -arR with the occasional pkgdb -fu

What happens when they don't agree?

[Delphis]

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.

Re:What happens when they don't agree?

[mrchaotica]

Sounds to me like one of them isn't following the Filesystem Hierarchy Standard...

Re:What happens when they don't agree?

[caseih]

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.

A step in the Right? direction?

[CrackHappy]

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.

Re:A step in the Right? direction?

[Nothinman]

Do you know how many packages I have installed on my 4 Debian machines that aren't in the Debian repositories? 2, if you don't count commercial apps that will never be packaged like VMWare or Q3.

I'm not saying it's perfect, but Debian sid has over 16,000 packages already so the chances are good that even if you can't find the exact package you want, you can find a workable alternative.

You're going to hate this but...

[TWX]

...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.

Re:You're going to hate this but...

[Anonymous Coward]

Not just Debian. Pretty much anything non-RPM based has no "dependency hell". Why do Debian, Gentoo, and the BSDs not have dependency hell? Because the repositories are controlled! RPM-based distributions will try to install anything from anywhere, and it's no big surprise that nothing matches up.

It's really that simple. Dependency hell is not a software problem. It's a management problem.

Re:You're going to hate this but...

[space_man51]

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!

Re:You're going to hate this but...

[Tet]

RPM still sucked massively and was fragmented between RedHat, SuSE, and Mandrake so badly that they couldn't use each others' RPMs.

Sigh. RPM didn't suck at all. The sole reason for your problems is RPMs popularity. If Ubuntu or Progeny or whoever acquires enough market share, I can guarantee you'll start to see the same issues cropping up with dpkg systems. Initially, it won't be a problem, just as Caldera and SuSE RPMs used to work fine on Red Hat and vice versa -- everyone strived to maintain compatibility with Red Hat. But as soon as a distribution ies to do something different, in an attempt to differentiate itself from the others, then you're headed down the same path that RPM has gone. There is nothing intrinsically better about dpkg than RPM, and dpkg systems' saving grace to date has simply been their comparative lack of success. I wish more people could see the reason things work well under Debian, rather than just blindly claiming RPM sucks.

Re:You're going to hate this but...

[Just Some Guy]

Why do Debian, Gentoo, and the BSDs not have dependency hell? Because the repositories are controlled!

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.

Re:You're going to hate this but...

[IamTheRealMike]

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.

Re:You're going to hate this but...

[killjoe]

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.

Re:You're going to hate this but...

[IamTheRealMike]

You don't realise they're broken because you're not a developer on those projects. I deal with broken Wine packages every week. I'm sure most of the people apt-getting and emerging away believe they are getting a quality tested package, but they're actually downloading crap-in-a-tarball.

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.

They call it Windows!

[Tumbleweed]

I've found a great solution to this problem!

No, you haven't.

Re:Why all the fuss?

[Anonymous Coward]

Yeah, the ease of installation of new packages is unbeatable! I just cruised a few websites, and all sorts of stuff was automatically installed.

what about ebuilds?

[Morganth]

I'm still compiling!!

Here's a coralized link to the screenshots, too:

no gentoo?

[Se7enLC]

deb...rpm...slack What? no Portage? what about my eBuilds?

Re:no gentoo?

[chill]

Okay, I'll say it.

Source-based packages have no place in a large scale environment. They do not scale.

The little boxes that sit in most offices and cubes have no business with a compiler on them, nor are people interested (nor should they be) in wasting time compiling applications.

Most office workers have a JOB to do that doesn't involve compiling software. As a corporate sysadmin I sure as hell don't want to have to use an eBuild for updating something like KDE or ANYTHING for that matter.

Gentoo is wonderful to experiment on and for very small installations, but I'd roll my own package manager before I would ever consider a source-based one.

-Charles

Re:no gentoo?

[Sweetshark]

Portage is overly complex.
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 .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.

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.

Re:no gentoo?

[eviltypeguy]

ebuilds are scripts, not packages. Next.

This is good

[skids]

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.

Wait and see

[brotherscrim]

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 don't make them require root access.

[Anonymous Coward]

The worst thing about package managers today is that ever UI pops up windows asking for the 'root' password. This is training lusers across the world that to install even the most trivial web browser, it's OK to type in root passwords whenever somethings pops them up.

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

Re:Please don't make them require root access.

[Beatbyte]

yes because giving unpriveleged users the right to run whatever binaries they want is a good thing..

btw, you need to enter the root password to see this message without the sarcasm.

Re:Please don't make them require root access.

[IamTheRealMike]

They already can. Investigate passing paths to ELF binaries to /lib/ld-linux.so.2, and if you figure out how to disable that (have a cookie if you can, it is possible!) then investigate ul_exec, LD_PRELOAD and ELF constructor functions.

Basically if a user has shell access to a box they can run whatever code they like. Deal with it.

Portage

[kaleco]

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?

Re:Portage

[Balinares]

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...

Re:Why all the fuss?

[0racle]

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.

Why can't we just pick ONE good way?

[mrchaotica]

...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).

OSX

[minus_273]

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.

Re:OSX

[Anonymous Coward]

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.

Re:OSX

[Mornelithe]

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.

Re:OSX

[TomorrowPlusX]

Speaking as an OS X developer, another thing this style of packaging tends to result in is devs who *want* the app to be easily installed.

Apple provides an "Installer" app for apps which *need* installation, and look how many people use it. Almost nobody.

The whole design guidelines of OS X and the general mindset that comes with living in and working on OS X is that an app should be one thing, an object, which can run anywhere and shouldn't require a billion libs to run.

And for those who gripe about not re-using libs, well, OS X apps *do* link against libs in /usr/lib and frameworks in /Library. So when OS X gets an update, everybody gets it.

Frankly, I don't miss running configure scripts and then manually installing a half dozen obscure libs to run a single app. If I -- a developer mind you on a well maintained system -- didn't have those libs already, how many people would? Just link it statically and deal with it. Criminy.

Re:OSX

[The Shrubber]

You want ROX-Filer, http://rox.sourceforge.net/

See also Zero-Install http://zero-install.sourceforge.net/, a seperate but related/compatible idea that tries to simplify matters even further.

Agree with parent: this kind of packaging system makes Macs very pleasant to deal with. This doesn't solve all our problems, but it is something we should use for apps (openoffice, etc).

Re:OSX

[ruyon]

Wasting a little hd space is much better than wasting my (and possibly countless other users') time.

Re:OSX

[Ian Bicking]

OS X installation is better suited to proprietary applications, as opposed to the more cooperative software system of a typical Linux computer. On OS X there are a clear set of system libraries that people can be expected to have. (And there's no incremental way to do major upgrades on that system software; also no free way).

When you only depend on system libraries, installation can be pretty simple. But there is little "system" on a Linux computer; libc is system. Is glib? libxml2? Who knows... various vendors define a base system, but it never means a whole lot, since Open Source developers aren't going to pay attention to it.

The Open Source environment encourages little applications and lots of dependencies. The package management has to be a lot more robust. Also, Linux package managers supports legacy applications, OS X does nothing in that case. It lets them run free and unmanaged. There's a virtue in OS X, that they provide clear and strong conventions to their developers; but the actual infrastructure is way less powerful or complete than any Linux distribution.

Re:OSX

[JW Troll]

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.

Lets start the fighting now.

[Anonymous Coward]

Things I want in a package manager.

1. Ability to upgrade from one major version to the next. Gentoo and Debian seem to handle this. Redhat and SuSE seem to make you re-install the whole OS.
2. 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.

Re:Lets start the fighting now.

[space_man51]

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.

I totally agree with that point. Allow the user to specify a directory to install "local" software and have the package manager intall to this directory when it doesn't have root access! Excellent.

Re:Lets start the fighting now.

[TWX]

"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.

Re:Lets start the fighting now.

[Pxtl]

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.

Re:Lets start the fighting now.

[aclarke]

Well when *I* was in school, I had to run Netscape on HP/UX, displayed on my local X Server running on a Windows 3.1 box. Displayed over a 2400 baud modem. Uphill. Both ways. In the rain.

With NOBODY to hold my hands. Because the life of the geek is a lonely life.

Re:Lets start the fighting now.

[pyros]

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.

Re:Lets start the fighting now.

[TWX]

"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.

Re:Lets start the fighting now.

[space_man51]

I don't know if any other package systems support this "install locally" feature. I've never heard about it in dpkg/apt-get. Also, as many have pointed out, it's the actual programs that have install paths hardcoded (although Debian could make it part of their policies that programs shouldn't hard-code any paths, since Debian packages must modify certain paths already).

Re:Lets start the fighting now.

[spitefulcrow]

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.

Re:Lets start the fighting now.

[Elwood P Dowd]

If you circumvent that, you do it at your own peril, and they're not going to make it easy for you to do.

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 /usr/local/bin or /usr/local/lib.

Why is this objectionable in any way? Are you trolling?

Re:Lets start the fighting now.

[adamruck]

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.

Re:Lets start the fighting now.

[grumbel]

Debian, at least in part. While apt-get sure can do it, one can't use apt-get in all situations. If you just pick a .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. Sure for larger repositories that is no problem, but for a single programm thats far to much hassle. What I miss is a simple:

$ apt-get install /tmp/mypackage.deb

Re:Lets start the fighting now.

[MHV]

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.

Same standard, multiple implementations

[mrchaotica]

Standards are great, but that doesnt mean there should only be one way of implementing something.

Yes, that's exactly right! However, it does not mean that we have to "treat each distro as a diferent OS," like the original poster suggested.

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?

Re:Same standard, multiple implementations

[space_man51]

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)?

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.

Re:Same standard, multiple implementations

[mrchaotica]

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.

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.

Reinventing

[paugq]

Reinvening Autopackage and OpenPKG once again?

Re:I give it a week.

[Kenja]

"You realiz this is being done by businesses? You know, who pay their developers to do what managment says. Somehow I don't think forking this thing which is intended to unify makes good business sense."

If its not open source, the geeks wont use it.
If the geeks dont use it, its not a unified package manager.
If it is open source, the geeks will fork it.

Re:Why all the fuss?

[Anonymous Coward]

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.

Politics

[lakeland]

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...

Re:Politics

[lakeland]

*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.

Re:Politics

[lakeland]

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.

1) Debian packages are distributed as a .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.

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, .... 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.

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

Re:Politics

[moZer]

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?

Wrapper hell

[grumbel]

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...

Ahem

[Azureflare]

RPM-based distributions will try to install anything from anywhere

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.

Re:Ahem

[fireboy1919]

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.

Re:I give it a week.

[Hatta]

If it is open source, the geeks will fork it.

Yeah, because there are so many forks of apt-get and URPMI. Besides, who cares if they fork it, as long as it still works as advertised.

Think about how this project is going to work. You don't have to use it. You can keep apt-get and totally ignore that this thing exists. But hey, if you happen to want something that hasn't been released in a .deb, this thing will install it for you. How is forking going to screw that up? They're going to take out that functionality?

Re:Drag-n-drop like OSX

[space_man51]

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:

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 .desktop file in the virtual folder that the user can drag onto his/her kmenu, panel, desktop, whatever (.desktop is already a standard).

To uninstall the program, the user simply drags the .desktop file to the trashcan. The package manager is invoked and uninstalls the program.

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Too much packaging....

[punkrockguy318]

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.

Re:Diversity != Confusion

[Slack3r78]

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.

Re:Why all the fuss?

[katharsis83]

"...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.

Re:how about

[Doctor Crumb]

stop using RPM. Debian has a central repository. Most non-RPM systems do as well. I recommend installing apt on any RPM system and using that to manage source lists and package control. It still uses RPMs, but it takes care of most of the dependency problems for you.

Agreed, they cannot forsee all conflicts

[Ars-Fartsica]

The problem with any of these wrappers is that they are trying to solve an intractable problem - making all package systems play together. Its been tried.

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.

gentoo, et al.

[mizhi]

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.

Re:gentoo, et al.

[antiMStroll]

Were you doing any customization? I've had problems for sure, but never anything more than a poorly configured emerge failing. However Gentoo doesn't replace binaries until a compile has successfully completed so worse case the result is a bit of lost drive space in var and waiting for a package fix.

Where gentoo realy needs help is its insistence of generating new config files with every core emerge and sitting the user through a hundred questions via etc-update. Retain, replace or merge /etc/foo? At least they stopped doing this for trivial header changes.

Re:Drag-n-drop like OSX

[The Shrubber]

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!

Here We Go Again, Geek Morons!

[Master of Transhuman]

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?

Not always installing the newest version

[Ed Avis]

I noticed one big difference between 'smart' and existing tools is that it will sometimes choose an older version of a package if that's necessary to get a smooth upgrade. As they say in the web page,

In this case, there's a package A version 1.0 installed in the system, and there are two versions available for upgrading: 1.5 and 2.0. Version 1.5 may be installed without problems, but version 2.0 has a dependency on B, which is not available anywhere.

In this case, the best possibility is upgrading to 1.5, since upgrading to 2.0 is not an option.

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.

Well..

[Theatetus]

My understanding of the FHS is that /usr/bin should be for important core utilities that are (or pratically are) part of the OS, not random applications.

Well... that may be what FHS says, but that goes against the tradition that the distros are following, namely:

1. /bin: the binaries you need to have to boot and init
2. /sbin: the binaries you need to have to boot that only root should be able to even know about.
3. /usr/bin: the binaries you don't need to have to boot and init, that you got through your vendor's bundling / package management.
4. /usr/sbin: binaries from your vendor that only root should be able to even know about.
5. /usr/local/(bin|sbin|etc|var|lib): a little miniature filesystem for all the stuff that you didn't get from your vendor.

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.

dragging icons?

[commodoresloat]

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.

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.

I'm "just" a user.

[Dorsai65]

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)

Re:If you want that kind of

[Kent Recal]

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.

"Framework" on Linux

[spitzak]

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.

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 /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).

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.

some obscure package

[obdulio]

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.

Re:Why all the fuss?

[Walles]

What if I want to install Gimp in /opt/gimp instead of where ever the package maintainer decided to put

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?