- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Why I won't upgrade my Linux distribution
|
|
|
Comments (1)
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
All technical solutions can be divided into two classes: easy on the creator's side and difficult/upsetting to use, or, difficult and work-requiring on the creator's side and a breeze on the user's side. RPM goes in the tradition of the first group. It is pretty easy to slap together an RPM package, but really there are no rules what it should look like inside. Get a tarball, put in spec file, run rebuild et voila, ready for the immediate release.
To have RPM working right you have to do more, like making a list of config files for the spec file, specifying dependencies on actual packages and not files (this is required for apt-get to work), and much more. And since this is not obligatory, not much packagers do this.
OTOH, for deb (Debian-style packages) files there is a list of things a package can. or cannot do. It is called Debian Policy, and it is enforced by package-verifying tools lintian and linda. For example /etc is Verboten to install files directly into. /etc is for configuration files and you just mark them as such during package-building process and they will be installed automagically into the proper place. And WON'T be overwritten during an upgrade. Period.
The downside is that it takes actual work to make a deb package. But it is almost the same amount of work you have to do for making a good RPM package. Only in RPM you have to have some of the things done by hand, while dpkg-dev (and debhelper) make most of the stuff work automagically.
The result?
I've been using deb-based distros (Debian bo, hamm, potato, woody, sarge, Xandros Desktop, Progeny) for years and never had to reinstall. Upgrade works usually smoothly if not flawlessly - the only things requiring manual intervention is stuff like upgrading version of Postgres databases for new engine, and it only needs some tinkering to adapt to local environment. Remote kernel upgrades work like a charm for debianized kernels.
Maybe someday, some vendor will make RPM Policy, too.