31

Why isn't there a unified package manager that acts as an interface between the end-user and the underlying low-level package manager (apt, yast, pacman, etc.)?

Is it hard to do and therefore not practical, or is there a genuine obstacle making it impossible to do?

migrated from programmers.stackexchange.com Oct 31 '11 at 13:43

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • 14
    My guess is that we will get a unified field theory long before we get a unified package manager... – Yannis Rizos Oct 31 '11 at 13:30
  • 26
    The problem, in a nutshell – Shadur Oct 31 '11 at 14:15
  • 2
    For the exact same reason we don't want a single distribution - I like the way my distro does it. If you don't, then you're free to use another or write your own. Before you know it, you have as many package managers as you do programmers. – new123456 Oct 31 '11 at 20:36
  • 2
    don't you mean the low-level package managers rpm, dep, source? The ones you listed are, themselves frontends. – frogstarr78 Oct 31 '11 at 23:17
35

First of all, there is. The problem is not that there is no unified package manager, the problem is there are ten of them – seriously.

Let's take my favorite: poldek. It's a user front end for package management that can run on several different distros and manage either rpm or deb packages. Poldek doesn't do the stuff rpm does (it leaves that to rpm) and just sends the right commands without the user having to figure out all that mess.

But the problems don't stop there. Everybody has a different idea of what a user front end is supposed to look like and how it should function and what options it should expose. So other people have written their own. Actually many of the package front end managers people use in common distros today are able to handle more than one backend.

In the end, however, the problem (or advantage) is people like things to function exactly the way they want, not in some meta-fashion that tries to satisfy everybody only to fail to really make anybody happy. This is the reason we have umpteen gazillion distros in the first place. It's the reason we have so many different Desktop Environments and Window Managers (and the fact those are actually different kinds of things at all).

There are still outstanding proposals for ways of writing universal packages or having a manager that understands them all or having an api for converting one to the other ... but in the end Unix is best when used according to its philosophy ... each tool does one thing and does it well.

Any time you have a tool that tries to do more than one thing, it ends up being not as good at one of them. For example, poldek sucks at handling deb package dependencies.

  • 1
    Pretty much what I was going to say. And frankly, as long as stuff interoperates decently under the hood (say, by adhering to the LSB standards) then I don't really see the problem. – Shadur Oct 31 '11 at 14:18
  • 10
    ++ for "UNIX is best when ... each tool does one thing and does it well". Sometimes I think too many tools are way off that path... – ktf Oct 31 '11 at 14:23
  • Put a link to poldek.pld-linux.org --- could be useful to investigate something that had last update in 2005. – sorin Dec 17 '16 at 16:46
10

In short: because each distribution uses different approach to package management. They are simply not compatible. Management strategy that works best for Ubuntu will have little sense on Arch etc. A "universal" (distribution-independent) package manager would be just an additional layer of user interface, that would never work as good as each distribution's specific manager.

So, using your own words, it is hard to do and therefore not practical - also because hardly anyone would benefit from it.

  • Package management solution's are portable to other systems. ive seen portage on debian. However the name of the game is to find something that works for the user, eg. it does not make much sense to make portage the default on ubuntu. We appear to be doing pretty well so far anyway. – Silverfire Oct 31 '11 at 21:54
8

Historical reasons, mainly. Several package management systems got established around the same time - particularly .rpm and .deb. Each has its adherents and each is good enough that no single package manager has a compelling advantage. The distributors certainly won't see the point in a ground-up rebuild of their system to implement a different package manager.

This also would require each package within the system (10,000's in the case of debian) to be rebuilt. It would also require a smooth migration system to be implemented so that users of the system could go from the old to the new package manager. The effort to migrate would be infeasibly large, and exponentially larger to test the migration, so you would almost certainly get many breakages. This would generate many irate punters.

Each distro maintains its own set of dependencies based on what was built for that release. A universal package repository will be too hard to coordinate amongst the distributions as dependency conflicts are almost certain to arise. Therefore the actual benefit of a unified package management system (universal packages) will be impossible to realise in practice anyway.

Finally, who gets to choose the universal standard package manager? The XKCD comic referenced in the comments on the OP summarises the usual failure mode in this type of exercise. Standardising this sort of thing would be very political and likely to result in something that is not usable, or so deeply flawed that it spawnes yet another round of handwringing about standards - if the parties can come to an agreement at all.

So, basically it comes down to: too political, too hard, too risky and no benefit to be realised by doing it.

8

What you described,

that acts as an interface between the end-user and the underlying low-lever package manager

sounds a little like PackageKit to me, that is,

PackageKit is a system designed to make installing and updating software on your computer easier. The primary design goal is to unify all the software graphical tools used in different distributions, and use some of the latest technology like PolicyKit to make the process suck less.

Edit: See here for a list of supported backends. Edit2: Removed useless remark.

6

First, understand that "Linux" is not an operating system. It is a kernel. A package manager is an OS-level concept, not a kernel-level one. Therefore asking for a unified package manager for Linux is not really sensical.

However, if you are asking why the various operating systems which use the Linux kernel don't have compatible package managers, well you may as well ask why Windows and Macs don't have compatible package managers. Or any other two operating systems.

Different OSes cater to different users' needs, and the package manager is part of it. Why don't all Linux distros have the same window manager? Or come with all the same pre-installed software?

Answer: Different strokes for different folks.

  • 1
    +1 for '"Linux" is not an operating system' – Silverfire Oct 31 '11 at 21:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.