On Fri, 28 May 1999, Steve Greenland wrote: > On 28-May-99, 14:21 (CDT), Santiago Vila <[EMAIL PROTECTED]> 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)
