Re: Provides: emacsen ?
Santiago Vila <sanvila@unex.es> 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: rob@io.com
--
To UNSUBSCRIBE, email to debian-policy-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: