Bug#38212: debian-policy: [PROPOSAL] rewrite of section 5.7
On Wed, 26 May 1999, Branden Robinson wrote:
> On Wed, May 26, 1999 at 11:25:19AM +0200, Santiago Vila wrote:
> > The fact that I am able to execute emacs or ghostscript in console mode
> > without xfree86-common shows that the dependency of xlib6g on
> > xfree86-common is not absolute, and therefore a "Depends:" field should
> > not be used for that. There is nothing in xlib6g which "breaks" without
> > xfree86-common.
>
> xlib6g does not exist just for packages that work in console mode. It also
> exists, surprise surprise, for packages that use the X libraries.
>
> Let us consider a similar argument.
>
> "The fact that I am able to write, compile, link, run, and package programs
> that do not use the C math library shows that the dependency of my programs
> on parts of the libc6 package is not absolute, and therefore a `Depends:'
> field should not be used for that. The C math library should be split out
> of libc6 because there are many packages that use the C library that don't
> `break' without libm.so."
I don't think this argument is similar:
If libm and libc were in different packages, we would have a different
shlibs file for each of them. Packages depending on the shared libc would
have a Depends: field on the package containing libc, and packages
depending on the shared libm would have a Depends: field on the package
containing libm, but neither libc would have to depend on libm nor libm
would have to depend on libc.
> > 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.
> You yourself have filed many bugs about this sort of thing, so I can only
> assume you are attempting to be provocative.
I'm sorry that you assume that. I'm just attempting to understand why you
made xlib6g to depend on xfree86-common.
> > > "Such programs should be configured with X support, and should declare a
> > > dependency on xlib6g (which contains X shared libraries)."
> > >
> > > This directive is unchanged from the previous version of section 5.7
> > >
> > > So, let's get things out in the open. Do you object to the proposal or
> > > not?
> >
> > Yes, I will object to this paragraph if it makes you to feel better.
> > But before that I'm asking for a good rationale for the proposed changes.
>
> You object to the whole paragraph? Including "Such programs should be..."?
> I did nothing except to change an explanatory sentence to be more accurate
> as regards existing, actual practice. I have not changed policy on this
> point in any way at all.
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".
This is exactly the opposite of what should be done: *First* change the
policy, *then* change the practice.
> 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.
So you add a gratuitous dependency and a gratuitous package and claim that
this is not actually a policy change.
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.
> [...]
> > No, I'm just saying that xlib6g's dependency (a "Depends" field, to be
> > precise) on xfree86-common is artificial.
>
> This issue is completely orthogonal to my policy proposal.
If it were completely orthogonal we would not be discussing about it.
[ ... snipped the rest of the mail ... ]
Please note (again) that I have not formally objected to your proposal
(i.e. by saying "I object to this proposal").
Thanks.
--
"4f2a983723a60256f245d979b13a81d7" (a truly random sig)
Reply to: