Dale Scheetz writes ("Re: New virtual package names. "): > On Fri, 9 Aug 1996, Ian Jackson wrote: ... > > Noone is going to deinstall all the editors on their system and not > > notice what they've done wrong and how to fix it - this is not the > > kind of `mistake' our dependency scheme should try to address. > > It was my understanding that this was EXACTLY what dependancies were > designed for; Protecting the installer from removing functionality that > other packages need.
Surely this is only useful if this is a mistake the user will be likely to make, and then not know how to undo ? > > The only possible consequences of creating an `editor' virtual package > > and having things depend on it are: > > * Needless updates to packages to add dependencies and Provides > > This is not a technical argument. It is an economic one, and should not be > listed as a primary point. (all change takes work) Your assertion that it > is needless is not yet backed up by technical arguments. In addition, the > modification of other editor packages to encorporate this new VPN are not > on any critical path, so they can happen as need arrises. I can't prove that it's needless. You're shifting the burden of proof. It's up to you to show that it's needed. > > * Some person installs their own favourite editor in /usr/local > > and wants to remove all ours but can't. > > This is true for any package that has others that depend on it. If I want > to put a qmail of my own into /usr/local, I will still need to keep some > Debian mail-delivery-agent installed to satisfy other packages dependance > on an MDA. A way to tell dpkg about "non-package provides" would fix this > problem in general, but I don't necessarily think that it is needed, or > even desirable. The difference is that an editor is such a fundamental and striaghtforward thing that it will be obvious to the user what they're doing without the dependency scheme having to tell them. You're using a sledgehammer to crack a probably-nonexistent nut. Ian.