Santiago Vila <[EMAIL PROTECTED]> writes: > Oh, I was told that when you upgrade, you are supposed to upgrade > everything, and therefore it does not matter if, for example, installing > libc6 in a bo system breaks the old emacs completely.
If it doesn't matter, it should. Hamm includes libc5 compatibility libraries, so why should we be willing to break *anything* if the only cost for doing it is the inconvenience of using a slightly awkward package name? It seems a small price to pay for quality. One of the great strengths of Debian is precisely that things do NOT break even as you replace individual packages during an upgrade, even if the system is *in use*. (In fact, that is what inspired me to pick Debian over the alternatives... I was poking through one of those multi-distro sets trying to pick one to try first. Then I saw the stuff about "upgrading a running system" and had to check it out...) In a bo->hamm upgrade, the only extra care that needs to be taken is in the first few packages -- libc6 and ldso and readline and bash etc. -- because if you do them in the wrong order, everything breaks. However, once you do that, you can upgrade everything else at your own discretion. I've done it twice, and on both occasions I took my sweet time downloading and installing everything, without ever losing the use of anything important. Another factor in this particular case was that the emacs19 package came along a lot later than the others. Even after I upgraded everything else, I kept running the old 'emacs' for several weeks, and it never broke. > Would not have been easier to keep the name "emacs" for emacs19, but > allowing other packages also to provide "emacs"? No, because the old "emacs" doesn't provide the same capabilities as what is now called "emacsen", and there is no way to force an upgrade. Dselect won't upgrade packages that are on hold; even if you had some other way to force the old 'emacs' out via conflicts, or whatever, you can't make the sysadmin install anything, so it is possible that an old 'emacs' could still be around (even if it is broken) while everything around it was upgraded. The way the packaging system works, it is not safe to have a virtual package be named the same as a real package, under any circumstances, because virtual packages are only provided by name without a version number. This hypothetical situation is a good example of why this doesn't work: in this case, there has to be a way to distinguish between the old 'emacs' and the new, compliant-with-new-policy 'emacs', but that's not possible when 'emacs' is being provided by something else entirely. The way it ended up being done, the naming scheme is consistent, and the only annoyance is with the name 'emacsen'. Oh well. I'm just thankful that (looks in docs) Mr. Browning et.al.(?) came up with the emacsen-common stuff -- now multi-flavor emacs support is another nice feature that nobody else does quite as well. --Rob -- Rob Tillotson N9MTB Internet: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
