Virtual packages
Section 2.3.5 says this:
> All packages should use virtual package names where appropriate, and
> arrange to create new ones if necessary. They should not use virtual
> package names (except privately, amongst a cooperating group of
> packages) unless they have been agreed upon and appear in the list
> of virtual package names.
In reality, most (all?) virtual packages seem to fall into the
category "except privately, amongst a cooperating group of
packages". As such, this paragraph doesn't seem to reflect reality
very well.
I could just propose a rewrite which made adding a package to the list
the special case instead... but I think this merits rethinking
anyway. What exactly is the list of virtual package names supposed to
achieve, and why should it constrain those which are used?
[I'm skipping the justifications for these various options, it should
be obvious; all of these should have an addendum of "and rewrite 2.3.5
accordingly"]
Option #1:
Ditch the whole thing. Leave it to maintainers to sort it out, and
replace this paragraph with guidelines about what virtual packages are
for.
Option #2:
As #1, but build a list of virtual packages during the policy build
process. This is based on the notion that the list is useful
documentation, but I don't think this is a very good idea; the list
would probably be out of date more often than not.
Option #3:
Ditch the file, and provide a tool in the debian-policy package which
finds the current list.
Option #4:
Define what is meant by "privately amoung packages" more accurately,
and rewrite the paragraph in terms of that.
Other ideas? I'm hovering between #1 and #4.
[Default option: bicker about it and get nothing useful done]
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ | Dept. of Computing,
`. `' | Imperial College,
`- -><- | London, UK
Reply to: