Re: Provides: emacsen ?
Santiago Vila <sanvila@unex.es> writes:
> Question: Which are those historical reasons? Why the nature of the
> packaging system prevent "emacs" to be the name of the virtual package?
The problem is that there is already an actual package (in bo) named
"emacs". It has been replaced by (x)emacs(19,20) in hamm, but it will
still exist on systems that are being upgraded. Since this "emacs"
does not follow the new packaging conventions for emacsen, it is
incorrect for new-emacsen packages to depend on "emacs" as that will
cause the installation to break. (Which is exactly what the packaging
system is supposed to prevent.)
This could cause a real mess for anyone upgrading to hamm. They would
already have an "emacs", so dselect et. al. would see nothing wrong
with upgrading all the other emacs-related packages -- and they would
all promptly break during install, or at the very least fail to work
right. The way things are done now might not be completely automatic,
but at least it won't cause the user's system to break for no easily
discernable reason... attempting to upgrade any emacsen-related
package will remind the user that they need emacsen-common and a new
emacs package of their choice.
Like it or not, the "emacs" name will have to be retired permanently,
if the goal of breakproof upgrades-in-place is to be maintained.
Enjoy,
--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: