When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .
Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.
Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time
So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.
Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.
Fatality two - why fatality one was met
All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.
This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).
Fatality three - why rpm based system fail to have upgrade support today
Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:
- new-preinst 2
- new-postinst 2
- old-prerm 1
- old-postrm 1
And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).
More bad ideas from the rpm land (glad not to be there)
In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.
They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.
1 comment:
I have repeatedly upgraded Fedora systems from 4 to 5, or 5 to 6, or 6 to 7, or 7 to 8, using yum. So are wrong in claiming that it doesn't work.
It is true that, for some reason, the Fedora developers discourage this path. Actually they do have a reason, because there is occasionally breakage due to brain-dead things like having an upgraded package in Fedora N appear to be newer than the same package in Fedora N+1. But that's just a matter of policy and lack of testing; the yum equivalent of dist-upgrade generally works quite well, and the bits of rescue required are similar to what anyone who runs Debian testing or unstable has to engage in.
That doesn't mean that RPM doesn't have design defects; the biggest is the lack of the notion of config files. But the .deb system is overly complex and grew new features over time.
Post a Comment