Re: [PROPOSED] Change package relations policy to remove references to non-free from main
- To: Joey Hess <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Re: [PROPOSED] Change package relations policy to remove references to non-free from main
- From: Chris Waters <firstname.lastname@example.org>
- Date: 02 Dec 1999 03:27:24 -0800
- Message-id: <email@example.com>
- In-reply-to: Joey Hess's message of "Tue, 30 Nov 1999 20:20:11 -0800"
- References: <19991129003946.B23998@mors.net> <firstname.lastname@example.org> <email@example.com> <19991130202011.E13120@kitenet.net>
Joey Hess <firstname.lastname@example.org> writes:
> Chris Waters wrote:
> > I have been unable to think of any actual legitimate use of enhances,
> > and you don't seem to be doing much better.
> Here, I've thought of one. Nextaw could be said to enhance xcontrib,
> because xfontsel in that package is rather useless without it (if
> you want to pick the 200'th font from a menu, you need something
> like nextaw to scroll that menu since it can't all fit onscreen).
In that case, why wouldn't xcontrib just suggest nextaw? This is
exactly the same as the last example, except that it's a "Suggests"
not a "Depends" this time. :-)
The use of the term "Enhances" may be misleading. What we're
discussing is basically a reverse "Suggests" field. Really, the
proper name for this field is: "I *should* have been suggested by".
And I think it's not as useful as a field whose proper name would be:
"Suggested only if available".
If this discussion is going to get anywhere, we have to call these
fields by names that don't confuse. I'll call 'em reverse-suggests
So, now I'll rephrase my original comment: I can't think of any
legitimate use of reverse-suggests that can't be met by
Just to be fair, I'll admit that I also can't think of any uses for
weak-suggests that can't be met by reverse-suggests.
However, I think that reverse-suggests is a much higher-maintenance
solution. It requires coördinated action by two maintainers, doubling
the chances for problems to arise. The more encapsulated package
maintenance is, the less of a hassle it is, and the less often we'll
have to deal with messes like the great perl upgrade drama.
Consider it from the point of view of someone maintaining a non-free
package that a lot of people want to have reverse-suggests from. Now,
you have to reupload a new version every time some new package gets
uploaded that needs to suggest your package. What a major hassle!
And not just to you but to everyone that has to download a new version
of your eight megabyte package all of a sudden, just to support this
new *reverse link*.
And let's not even think about what happens when someone needs a
versioned reverse-depends! The mind boggles!
The weak-suggests solves these problems. The only valid objection to
weak-suggests I've seen is that it *is* possible (with a little work)
to figure out which non-free packages would have been suggested if
they had been available. I'm not entirely convinced that's a bad
thing, and even if it is, it's still a much more minor problem than
the serious technical and logistical flaws in reverse-suggests.
The other objection I've seen is, basically, "the purity of the system
is marred by the very presence of even the *names* of non-free
packages." My opinion of this notion is unprintable. :-)
As I've said before, I won't use reverse-suggests (no matter what you
call it). I'm not an enemy of the DFSG -- I don't have *any* non-free
suggestions at the moment *even though I could*. But I'll just keep
it that way, if this proposal eventually passes. OTOH, I *would* use
weak-suggests. I might even use it for other things than just
non-free -- it could be handy for making the system easier to break up
into functional subsets.
Chris Waters email@example.com | I have a truly elegant proof of the
or firstname.lastname@example.org | above, but it is too long to fit into
http://www.dsp.net/xtifr | this .signature file.