Re: emacs -> emacs19. Why?
Rob Browning <rlb@cs.utexas.edu> writes:
>
> Right. We don't want to be in the business of deciding which emacs is
> the "one true emacs". We'll leave that for the clerics. Given that,
> the old emacs needed a name change. What I'm *not* sure about (though
> there's probably a reason I'm not thinking of now) is why we can't
> have emacs19 conflict and replace emacs. That would eliminate the one
> legitimate objection (IMO).
No, it wouldn't eliminate the objection.
The problem is that if you run dselect it won't suggest installing any of the
new emacsen and thinks there's nothing wrong with the old emacs. In fact it
does already conflict and replace emacs (<=19.34-13).
The only way to solve it using the existing dependency handling would be do
add the long list of packages that don't work with the new libraries in a
Conflicts header of libc6. Or possibly we could make an empty required base
package with the dependencies to force people to upgrade the old broken
packages.
In the long run we need APT to be a bit more clever than dselect in
discoverying packages that have changed names. Currently it displays packages
that are not up-to-date separately but doesn't realize when the new version
has a different name. In that case the user has to go digging in the
uninstalled packages for similar sounding names.
greg
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: