Dependencies in control files
There seems to me to be a problem with the way package maintainers
decide which packages to list as Depends or - especially - Recommended
in their control files.
Every time I do a dselect-based installation I end up submitting many
bug reports of the form `foo recommends bar but would work perfectly
well without it'.
I propose the following solution to this problem:
When a package maintainer wishes to add a dependency on or
recommendation of another package to their control file (or, when they
first begin to construct a package), they should post the control file
they intend to use to debian-devel. (There should probably be an
exception for groups of closely-related packages from the same
maintainer, where the internal relationships don't need any inter-
maintainer coordination.)
This will give the maintainers of any other related packges the
opportunity to suggest the use of virtual package names and to agree
what those names should be, to downgrade overly-strong dependencies,
and to ask that the package be made to conflict with others.
dselect uses the Packages file to decide what to let the user do
(though they can override it it is hard work to get such overriding to
stick - which is entirely the intent). Inappropriate relationships in
the Packages file are therefore a problem which should be fixed, and
since the Packages file is simply the concatenation of the control
files of the available packages it is probably necessary to arrange
for a bit more communication between package maintainers.
Someone is bound to suggest that the right way to do this is to have a
central authority rather than to use debian-devel. Well, (a) I
disagree, because it would require the maintainers of `foo' and `bar'
to communicate through the central authority, who must be aware of the
substantive interrlationships between all packages in order to do
their job, and (b) we don't have a volunteer anyway.
Ian.
Reply to: