Santiago Vila <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
