Santiago Vila <[EMAIL PROTECTED]> writes:
> The old emacs does not provide *any* capability in a libc6 system.
> It just core dumps ;-)
That's news to me, unless I was imagining things for a couple of weeks
between the beginning of the freeze and the availability of 'emacs19'.
Given that I use emacs on this machine for approximately 12-14 hours a
day, 7 days a week, I think I would notice if it was core dumping on
an otherwise all-libc6 system.
Even if that were not the case, however, there is still a policy point
here. Lets assume that the package 'emacs' will break during a libc6
upgrade. Now, how about this scenario:
0. system starts off running all libc5. 'emacs' is at v19.34-1
1. sysadmin upgrades the basic stuff to libc6, breaking 'emacs'.
2. sysadmin begins upgrading other packages. He's on a slow modem
line, so he does small ones first. He sees that 'emacs' is still
at the same major version number, except now it's something like
v19.34-5. "Oh, it's just a libc change," he thinks, "no reason
why that should break. After all, all my other libc5 programs
still work with the compatibility libraries." It's big, so he
decides to wait.
3. One of the packages installed in the upgrade is a new-policy
elisp package. It depends on "emacs", which is satisfied. It
breaks. "WTF?" the sysadmin says, "What is this
/usr/lib/emacsen-common/emacs-package-install crap?"
Now, how do we avoid this?
At step #1, we already have a bug. Non-essential packages should not
break on an upgrade at all -- if they are known to break, they should
be removed by an appropriate conflict in the packaging system.
Otherwise, if a package silently breaks without notice from the
packaging system, it should be considered a bug... and a rather
serious one, in my opinion.
At step #2, it might be easy to say "force the emacs to be upgraded".
But how is that supposed to happen? Dselect won't override holds, and
there is no way to force the sysadmin to read documentation that might
mention the problem.
Once again, the only possibility is to conflict the old package off
the system and maybe put something else in its place. Otherwise, it
is possible that the old package will remain on the system -- sure, it
might be broken, but the packaging system doesn't know that.
At step #3, we have yet another problem. What we would like is for
the elisp package to depend on "emacs (>= 19.34-5)", so that it
can guarantee the presence of the new behavior. However, it can't do
that if it wants to work with the other flavors, because they only
provide "emacs". Therefore, either the elisp package has to only
depend on "emacs", or we force everyone to install emacs 19 *and*
their flavor of choice. But if the elisp package only depends on
"emacs", the packaging system doesn't know it will break when an old
version of 'emacs' is around.
(It is also worth noting here that even if the sysadmin DOES choose to
upgrade 'emacs' at the same time, it is possible that dpkg will choose
to configure the packages in the wrong order. As far as I know, there
is no guarantee of order unless the dependencies actually force it to
be so.)
The point is that having a virtual package and a real package with the
same name leads to confusion and potential package system breakage.
Personally, I would much rather stick an 'en' onto the virtual package
name than weaken the package system's ability to do the right thing.
The current setup will have the desired effect: there won't even be an
'emacs', and any attempt to upgrade any add-on package will
do the right thing, installing emacsen-common and removing 'emacs'.
Personally, I wouldn't care if 'emacsen' was renamed to a random
string of bytes, as long as the end result was a non-broken
distribution.
--Rob
--
Rob Tillotson N9MTB Internet: [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
