On Thu, May 27, 1999 at 11:46:28AM +0200, Santiago Vila wrote: > > > You have decided that xfree86-common has to be of standard priority. > > > I think this is not ok because it is not needed at all. > > > > I have made no such decision. The decision was made for me. > > > > When package A has a higher priority than package B, we do not allow > > package A to depend on package B. > > I know. > > However, if we do not allow xlib6g to depend on xfree86-common, the simple > way of dealing with this would be not to make xlib6g to depend on > xfree86-common, since xfree86-common is not of standard priority.
Ah, I see. If things were different, they wouldn't be the same.
FACT 1: xlib6g is of standard priority
FACT 2: xlib6g depends on xfree86-common
POLICY: packages do not depend on other packages with lower priority
THEREFORE: xfree86-common is of standard priority
You don't like "FACT 2". I'm sorry, but it's not an issue of policy.
> I'm sorry that you assume that. I'm just attempting to understand why you
> made xlib6g to depend on xfree86-common.
Your attempts are feeble. I keep offering explanations, you keep saying,
"no, I don't like that."
> Oh, come on. First you change "existing practice" without changing policy,
> and then you change policy to be "more accurate as regards as existing
> practice".
Perhaps you hadn't noticed, but Debian Policy does not prescribe procedure
for every aspect of the Debian packaging process.
The purpose of section 5.7 is to inform packagers of programs that use the
X Window System with some standards so that the programs work well within
the X environment of a Debian system.
The existence of the xfree86-common package has changed not at all.
Packages were to depend on xlib6g before, and they depend on xlib6g now.
They do not have to depend on xfree86-common.
> This is exactly the opposite of what should be done: *First* change the
> policy, *then* change the practice.
If the practice is something that is germane to policy, yes. If it is
something that impacts other people's packages and imposes constraints on
how they handle their packages, yes. Otherwise, it usually is not.
Debian policy does not, for example, dictate the number of spaces/tabs to
be used for indentation in package maintainer scripts.
> > Before my changes:
> >
> > * Packages had to be configured with X support, and depend on xlib6g.
> >
> > After my changes:
> >
> > * Packages have to be configured with X support, and depend on xlib6g.
>
> No.
>
> Before your changes:
>
> Users who wish to use the program can install just the relatively small
> xlib6g package, and do not need to install the whole of X.
>
> After your changes:
>
> Users who wish to use the program can install just the relatively small
> xlib6g and xfree86-common packages, and do not need to install the whole
> of X.
The former ("Packages...") is a statement of policy. It tells package
maintainers what they need to with their packages if certain criteria are
met.
The latter ("Users...") is an informative statement.
You completely excised my discussion of informative versus normative
statements. Is this because you do not understand the difference? Or is
it simply because you are arguing for argument's sake, and attempting to
create the false impression in other people's minds that my introduction of
the xfree86-common package is somehow in violation of Debian policy?
You also failed to address my point about a possible xlib6g-dummy package.
Such a package probably would have no need to depend on xfree86-common, and
there is not going to be any kind of X installation on the machine.
Therefore no X servers or clients will be present looking for the things
OTHER than shared libraries that they require, and whose purpose it is
xfree86-common's to provide. (I say probably because no one has yet
implemented xlib6g-dummy and we don't yet know what issues other than
symbol resolution may arise.)
You are attempting to dumb xlib6g down to the level of xlib6g-dummy, which
does not exist.
> So you add a gratuitous dependency and a gratuitous package and claim that
> this is not actually a policy change.
You characterize them as gratuitous only because you are too obtuse to
understand the issues.
There is more to the X Window System than a set of shared libraries. We
would not need "Depends:" lines in control files at all if dpkg-shlibdeps
could discern everything that is necessary. But it doesn't. There are
issues other than shared library dependencies to be considered.
To understand what they might be, I suggest familiarizing yourself with the
contents of the xfree86-common and developing an understanding of what
these things are for.
> Suppose you make xlib6g to depend on five X packages. You could say:
>
> Users who wish to use the program can install just the relatively small
> xlib6g and these five other X packages, and do not need to
> install the whole of X.
>
> And as long as those five other X packages are not the same of "the whole
> of X" you would still claim this is not really a policy change. Is this
> how do you interpret current policy? I think this interpretation is
> flawed.
It is an informative, not a normative statment. It is the job of the
package tools (dselect, apt, et al.) to select for installation packages
that are depended-upon by another package slated for installation.
> If it were completely orthogonal we would not be discussing about it.
You presume that you have perfect understanding of the proposal and of the
issues involved. We are discussing it because you remain confused despite
my efforts to explain things to you.
> Please note (again) that I have not formally objected to your proposal
> (i.e. by saying "I object to this proposal").
All right.
--
G. Branden Robinson | Yesterday upon the stair,
Debian GNU/Linux | I met a man who wasn't there.
[EMAIL PROTECTED] | He wasn't there again today,
cartoon.ecn.purdue.edu/~branden/ | I think he's from the CIA.
pgpqb3lQUaTgb.pgp
Description: PGP signature
