Linked by Jason Vagner on Fri 16th Apr 2004 20:37 UTC
O'Reilly's latest entry in the "Pocket" series, "Linux Pocket Guide", bills itself as a "quick reference for experienced users and a guided tour for beginners".
Permalink for comment
To read all comments associated with this story, please click here.
If I did the whole paste&reply thing, I'd be taking up too much space.
I see your point, but I still disagree. If a distribution is grossly, out of date, my suggestion would be to switch. Updating versions is not that hard, and a distribution with a poorly maintained package collection is probably also poorly maintained itself
Anyway, I think your point is that if there were one package format, since fewer maintainers would be required across all the distributions, updates would push faster and more consistently.
This line of thinking seems to imply that the bottleneck is constant through all the distributions; i.e. it is having to make unique packages for new versions of software that takes time, not lengthy beaurocracy.
It is precisely the beaurocracy that is the problem. Many distributions (e.g. Debian) have really rigorous procedures to follow to get updates pushed onto the servers. Others do not. Other distributions are just slow.
Finally, .deb, .rpm, and many others can all do anything that a 'universal' package format would have to do. We need to separate the package manager (the backend) from the end user frontend (e.g. apt, yum) that interacts with both the package manager and some kind of ports tree. I think that just as gcc makes a symlink to gcc called cc, and well-built Makefiles call 'cc' and thereby ignore what c compiler is actually installed, these frontends should also have a generic symlink.
Having built a lot of packages, I would much rather see source tarballs standardize to the point where making packages could be automated.
If I did the whole paste&reply thing, I'd be taking up too much space.
I see your point, but I still disagree. If a distribution is grossly, out of date, my suggestion would be to switch. Updating versions is not that hard, and a distribution with a poorly maintained package collection is probably also poorly maintained itself
Anyway, I think your point is that if there were one package format, since fewer maintainers would be required across all the distributions, updates would push faster and more consistently.
This line of thinking seems to imply that the bottleneck is constant through all the distributions; i.e. it is having to make unique packages for new versions of software that takes time, not lengthy beaurocracy.
It is precisely the beaurocracy that is the problem. Many distributions (e.g. Debian) have really rigorous procedures to follow to get updates pushed onto the servers. Others do not. Other distributions are just slow.
Finally, .deb, .rpm, and many others can all do anything that a 'universal' package format would have to do. We need to separate the package manager (the backend) from the end user frontend (e.g. apt, yum) that interacts with both the package manager and some kind of ports tree. I think that just as gcc makes a symlink to gcc called cc, and well-built Makefiles call 'cc' and thereby ignore what c compiler is actually installed, these frontends should also have a generic symlink.
Having built a lot of packages, I would much rather see source tarballs standardize to the point where making packages could be automated.