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." > 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. You yourself have filed many bugs about this sort of thing, so I can only assume you are attempting to be provocative. > > "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. 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. > > > When I asked about xlib6g's new dependency on xfree86-common, people said > > > "this is to avoid a lot of packages to depend on xfree86-common". Well, > > > hiding real dependencies via indirect dependencies is not the way things > > > are usually done in Debian. > > > > Are you asserting that there is no dependency chain in Debian that is > > deeper than one level? I beg to differ. > > 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. > > > Which exactly is the problem which is intended to be solved by adding this > > > dependency? > > > > Read the package description of xfree86-common. > > I did. > > "xfree86-common contains the filesystem infrastructure required for > further installation of the X Window System in any configuration". > > So if I am not going to install the X Window System and only want to > execute packages linked against xlib6g in text mode, I do not need this > package at all. xlib6g is part of the X Window System. It is very reasonable to install xlib6g, but not any X servers, if you want a machine to be an "applications server" to other machines on the network, which run their own X servers. So, if you are going install part of the X Window System and only want to execute packages linked against xlib6g in text mode, you do not need the infrastructure that is required if you install part of the X Window System? What you really want is an xlib6g-dummy package. This issue is completely orthogonal to my policy proposal. Once such a beast exists and demonstrably works, it will be perfectly reasonable to amend the policy manual to *inform* people that xlib6g-dummy can be installed in lieu of xlib6g itself (and xfree86-common). Again, the part about what users to install is an *informative* statement, not really a *normative* one. See the Debian Constitution for a more exhaustive treatment the difference. Perhaps we should overhaul the Policy Manual to use iwj's "italics" method as well, for the benefit of people who have difficulty discerning the distinction between normative and informative statements. This will STILL not change the actual statement of policy. Stuff that is built against the X libraries will still declare a Depends: on xlib6g. Read up on dpkg-shlibdeps if this puzzles you. > > Do you object to the proposal? Do you have an amendment for it? > > I'm not objecting to the proposal yet, I'm still asking for a good > rationale (and I don't see a good rationale yet). There are a great many things you seem to have trouble seeing. That's not really my fault. BTW, if you object to the paragraph above, as you said you did, then you are objecting to the proposal. You don't get a "line-item veto". I will assume you are going on the record with your objection, therefore. You may, of course, withdraw your objection at any time, but if you haven't done so within two weeks, the proposal will be stalled. Thank you for your productive efforts. -- G. Branden Robinson | Psychology is really biology. Debian GNU/Linux | Biology is really chemistry. [EMAIL PROTECTED] | Chemistry is really physics. cartoon.ecn.purdue.edu/~branden/ | Physics is really math.
pgppfmb8Q1ysE.pgp
Description: PGP signature
