Re: xlib6g and xfree86-common

[Santiago Vila <sanvila@unex.es>]

On Fri, 28 May 1999, Steve Greenland wrote:

> On 28-May-99, 14:21 (CDT), Santiago Vila <sanvila@unex.es> wrote: 
> > Thu, 27 May 1999, Branden Robinson wrote:
> > > FACT 2: xlib6g depends on xfree86-common
> > I was talking about your implicit statement:
> > 
> > "xlib6g must have a Depends: field on xfree86-common".
> > 
> > from which FACT 2 derives.
> > 
> > This is an issue of policy if (as I think) xlib6g does not depend in
> > an absolute way on xfree86-common.
> 
> I disagree; it is *not* a matter of policy. From the packaging manual,
> section 8.2:
> 
> "The Depends field should be used if the depended-on package is
> required for the depending package to provide a significant amount of
> functionality."
> 
> Whether or not xlib6g *by itself* provides a "significant amount of
> functionality" is up to the maintainer, not policy. [...]

We are not discussing about the functionality xlib6g provides by
itself, but about the functionality xfree86-common provides to xlib6g.

In this case, it is xfree86-common who has to provide a "significant
amount of functionality" to xlib6g for xlib6g to Depend on xfree86-common.

If policy/packaging-manual/whatever-manual-you-prefer is not clear about
what is understood as "significant amount of functionality", then the door
could be open for arbitrariness.

When I have asked in the past about the functionality xfree86-common
provides, the only answer I have obtained so far has been about the
functionality it provides to X packages, *not* to xlib6g itself.

xlib6g main functionality is to satisfy the dynamic linker by resolving
the functions into appropriate code. How much better does xlib6g satisfy
the dynamic linker when xfree86-common is present?

This is the real question I would like to see answered.

> As a practical matter:
> 	xlib6g: Installed size: 3173
> 	xfree86-common: Installed size: 248
> So what's the big deal?

I agree it's not a "big" deal, but of course this does not mean that every
dependency of a 3173K package on a 248K package is automatically right.
The dependency should be examined by its own merits.

Thanks.

-- 
 "2097480730f4ea98dfdd8cc0a821ffe7" (a truly random sig)