Re: xlib6g and xfree86-common
(I've rearranged a few of the quotes.)
On 03-Jun-99, 12:40 (CDT), Santiago Vila <sanvila@unex.es> 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
Reply to: