(I've rearranged a few of the quotes.) On 03-Jun-99, 12:40 (CDT), Santiago Vila <[EMAIL PROTECTED]> wrote: > On Fri, 28 May 1999, Steve Greenland wrote: > > 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.
But that's not what the paragraph says! Here it is again, with *emphasis* added: "The Depends field should be used if the *depended-on* package is required for the *depending* package to provide a significant amount of functionality." Xfree86-common is the depended-on package, xlibg6 is the depending package. Therefore, it is the functionality that xlibg6 provides that is of interest. > 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? Crap. Xlib6g's main functionality is to provide services to X servers and X clients. The maintainer has determined that some of those services require the files/resources/whatever that are provided by xfree86-common. Therefore, the functionality requires the dependency. If you can show that a non-trivial sample of X clients or X servers can run a machine that has the xlib6g package installed but not xfree86 common, then you might have a case. Emacs running in a console doesn't count. > 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. Of *course* it's open for arbitrariness. Lots of things are up to the maintainer. Technical decisions are the perogative of the maintainer. Read the constitution. > 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. That's all it has to provide, because that is the functionality that xlib6g provides. The (presumed) point of separating xlib6g from xfree86-common is that xfree86-common is not platform specific. If Branden merged the packages, would you be happy? (Branden, I'm not suggesting you do so.) Steve
