Tomorrow, Ubuntu's second 'long-term support' release, 8.04 or Hardy Heron, will propagate its way through the list of mirrors. OSNews took a short look at the beta release of Hardy Heron a few weeks ago, and concluded that "All in all, this release packs some interesting new features and frameworks, some of which should have been part of any Linux distribution three years ago. It is quite clearly a beta though, and definitely not ready yet to be labeled as a 'long term support' release." In anticipation of the release, El Reg caught up with Mark Shuttleworth in London.
To read all comments associated with this story, please click here.
Member since:2007-07-25
I am also very interested in seeing all the package management getting unified, but when even the same damn format is so dependent on the individual distro its no point. Like ubuntu debs being ubuntu specific and will not necessarily work on other distros that use debs...
I like the way Mac OS X has solved packet management though...
Member since:2005-07-06
Member since:2007-09-22
Maybe you didn't know this, but Mac uses deb underneath as well. :-)
So when you say, I don't like how the deb-distributions can be incompatible, but I like how the Mac handles it. You might not be making as much sense as you think you are.
As Mac is 'just' an other very-much-incompatible deb-based 'distribution'.
Update: fixed 2 typos, there might still exist other problems.
Edited 2008-04-23 22:32 UTC
Member since:2006-08-01
Member since:2006-01-10
Yeah, I find this annoying too. In some sense there are reasons that they deviate a bit, like the restricted manager and restricted modules package. They make it rather difficult to compile in individual drivers. Debian's system using module-assistant makes it so much easier to install or uninstall (especially uninstall).
A lot of packages don't have this problem in the same way as trying to use a SUSE RPM on Mandriva would have. SuSe at least has gotten better. I remember when their naming scheme for RPMs were just *name*.rpm (like gimp.rpm) and not have any version numbers at all.
Most Ubuntu packages will work in Debian and most Debian packages will work in Ubuntu. In fact if you pay close attention, the maintainers are often the same people.
Member since:2005-07-06
This is already happening, at least at the end user level. PackageKit is the unifying element.
Packagekit integrates well with other elements of modern desktop Linux such as Policykit and D-Bus.
It provides both CLI and GUI frontends, even though the GUI is mostly Gnome for now. A QT version is under development.
PackageKit can handle all sort of packaging formats, debs and rpms included. So, in essense it will make the packaging format irrelevant to the end user.
As for rpm based distros to drop rpm, I would say that this will never happen. For a distro to be Linux Standard Base compliant it must be able to handle rpms, currently debian based distros do this through alien.
Naturally, it makes no sense to have developers learn two different, but very similar in feature set, packaging formats when it will be all the same to the end user. So, if we can't come up with something that is significantly better than rpm and debs, I would say that the best way to go would be if everybody sticked to RPM, as it currently is part of the LSB standard.
However, whats more important than the choise of packaging format is that a package providing functionality X have the same version number in all distros.
Perhaps distros should join forces and create some kind of metapackages, so that you could refer to a Linux distro as e.g. GNU/Linux x.xx/2,6.25.x compatible
These metapackages should at least cover the functionality of LSB.
Doing this would be benefishal to all Linux distros including the big ones, as it would make a Linux a more
well defined target for people and companies that want to port their software to Linux. With a little luck, perhaps even Adobe could be persuaded to port their software, if this happened.
Member since:2006-07-16
PackageKit and SMART (and even Klik) are/were great ideas for unifying package management. What you're forgetting about, however, are the large egos of the developers (and hordes of unquestioning followers) of the various disparate package management systems in use today. As an example, look at what occurred recently when the original developer of RPM tried to bring RPM from the dark ages into the modern times with RPM5. Someone at Red Hat had a snit fit and the new format ended up forking rather than being implemented downstream. Regardless, I agree that a unified package management system (if even on the surface) is essential if Linux is to continue growing on the desktop.
Member since:2007-07-10
I was waiting for the flip. I was waiting for the sarcastic, elitist, generally anti-ubuntu proclamations that everyone should release in lockstep. It never came.
But, even tho I use ubuntu,
(and arch)
(and freebsd)
it would be a horrible thing if every distro released at the same time. The give and take of release timing and targeted features keeps up the competition between distros. E.G. : branding-wise, I have no reason to switch to fedora, but fedora 9 will ship with kernel-based mode setting for my laptop - a feature I would love to have. Had they released this earlier, I wouldn't be able to take advantage of it. In the end, even normal users benefit from differing release cycles.
Member since:2005-07-11
The only way that will happen is if all (or any!) of the distros would get off their asses and clearly delineate what is "base OS" and what is "third-party apps" and get out of the "everything in the repos is the OS" mentality. Until they can separate things such that you can install new third-party apps with ease, based on a known-stable-base, without having to upgrade the entire distro to do so, we will not get anywhere.
And no, "backports" repos don't cut it.
Member since:2006-09-27
Now, what about unifying package management too? Would the RPM distros be willing to drop YUM, URPMI, YAST and switch to deb/APT? Again, I'm afraid that's asking too much, but who knows, maybe some day...
Rolling release need not be for geeks. For instance, PCLinuxOS is pretty much a rolling release (except a re-basing every few years), and it's one of the most newbie-friendly distros. It seems that Mepis will go this way as well, now that it rebased on Debian stable after the fiasco of trying base on Ubuntu.
Anyway, I think package management is an open problem in GNU/Linux. Ideally, one should be able to add as many unofficial repositories as one likes without worrying about conflicts, about "polluting" the system. Most package management systems assume that repositories are well-behaved and don't conflict each other. That's too much to assume in the Linux world.
Some people point out that proprietary operating systems like Mac OS X, or FOSS operating sytems which separate the core system from the third-party programs (like FreeBSD with its ports) don't have this problem. Well, one may say they do have to face this problem, but they hide it behind scenes while they develop the "core system", which is then presented to third party developers as a finished product. When the core system is developed in a more distributed way, as in GNU/Linux, the problem shows more clearly.
I may have voiced this opinion before, sorry for repeating myself
Member since:
2006-04-28
I agree that synchronizing releases would be a good thing for every distro and for 3rd parties. As Linux becomes more mature there is not the need anymore to release too often with all the new stuff and to innovate constantly. Now Linux needs to stabilize a bit, put more resources into QA, focus on normal users' needs, etc...
For example, if all the major distros agreed to release once a year during the same month, and use the same versions of each package, things would be much easier for everyone. You would just say: "I have X problem,I'm using Linux 2008", and that would be it. No need to say you're using distro X that has version Y of this package and version Z of that other package. Bug fixes would run across all distros rapidly, 3rd party packages would just have to care about the year of the release, etc...
The 6 month release cycle is good for enthusiasts and for rapid development, the rolling release method is good for geeks, developers, etc... But for normal users, one release per year is better (or even one every two years, but that might be asking too much for now...)
Now, what about unifying package management too? Would the RPM distros be willing to drop YUM, URPMI, YAST and switch to deb/APT? Again, I'm afraid that's asking too much, but who knows, maybe some day...