Reasons for the removal of "editor" virtual package
G'day,
>From recent messages on the list, it seems that some people are not familiar
with the reasons why the "editor" virtual package was removed. So this
piece of mail is an attempt to remedy the situation, by giving my
perspective on the issue.
The problem:
Some packages require an editor to be present on the system to
function correctly.
The old solution:
ae was marked essential, so it would always be there as a last
resort.
The problem with the old solution:
Some people wanted to remove ae from their systems because they
never used it, and didn't see why it should be essential.
The proposed new solution:
Have any package requiring an editor depend on a virtual package
"editor", and have every editor package provide "editor", thus
ensuring there would always be an editor available. This would also
allow the removal of the "essential" flag from ae, which could then
be removed if another editor was present on the system.
The problems with the proposed new solution:
How does a package which depends on having an editor know which
editor to use? Normally it consults the $EDITOR environment
variable, but what if that's not set, or is set to point to
something which isn't there? In the past, packages have been able
to assume that ae is present, and were able to fall back on using
that. OK, so they should be able to fall back on using the editor
that is satisfying the dependency, but how do they know which one,
and where to find it? And if they can't know these things, what's
the point of making sure the dependency is satisfied when the
program is going to break anyway?
There's also the problem of what if the user has installed their own
editor in /usr/local? The dependency then gets in the way (but this
is true for many virtual packages).
Ian also argues that this is too high-level a problem for the
dependency mechanism to be an appropriate solution, and that a user
is going to know what the problem is if they want to edit something
and no editor is installed. I agree, up to a point. As long as any
program that can't find an editor gives the user some meaningful
feedback about this, then it's fairly straightforward for the user
to fix the problem. Of course, I'm sure there are programs out
there that *don't* give meaningful feedback if calling the editor
fails... Of course, I also argue that such programs are broken and
should be fixed. :-)
The current situation:
ae is no longer essential, and there is no way to guarantee an
editor is installed.
So anyway, the conclusion was that having the editor virtual package was
pointless, at least until, say, a neat way of matching up the depender with
the dependee was found (maybe something could be done with the alternatives
mechanism? I don't know enough about it). And even if a neat solution
could be found, it's still questionable as to whether it's worthwhile.
I'd rather not start another long thread arguing about all of this, so I
guess I'd request that if you do have some neat idea about how it could all
be done, that before you start you have convincing arguments for:
1. Why fixing packages that depend on an editor to print a suitable message
is not a good idea, or is not a sufficient solution to the problem.
2. Why using a virtual package and dpkg's dependency mechanism is the right
way to solve the problem.
Thanks,
Warwick
----------------------------------------------------------------------------
Warwick Harvey email: warwick@cs.mu.OZ.AU
Department of Computer Science phone: +61-3-9344-9171
University of Melbourne fax: +61-3-9348-1184
Parkville, Victoria, AUSTRALIA 3052 web: http://www.cs.mu.OZ.AU/~warwick
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: