[ I'm using a new thread so that we do not use the proposal thread any longer ].
Thu, 27 May 1999, Branden Robinson wrote: > 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. Of course not, if the meaning of "depends" is "has a Depends: field in the control file". But this is not what I was referring. I was talking about your implicit statement: "xlib6g must have a Depends: field on xfree86-common". from which FACT 2 derives. This is an issue of policy if (as I think) xlib6g does not depend in an absolute way on xfree86-common. The fact that some programs (which policy describe as those which may be configured with or without X support) work fine with xlib6g and without xfree86-common, while *no* xlib6g-dummy package does still exist (this is important) makes me to think that a Depends: field is too strong as dpkg field for the dependency of xlib6g on xfree86-common. Granted, I have absolutely no idea about how these programs would behave if we replace xlib6g by xlib6g-dummy, but until xlib6g-dummy exists, it is perfectly reasonable to execute those programs in console mode without the need of xfree86-common. Is there something that have changed in the X packages that makes executing these programs under console more unreasonable than it was in the past? You say I'm attempting to dumb xlib6g down to the level of xlib6g-dummy. Well, I think this is exactly what point 5.7 in policy suggests: that we may well consider xlib6g as some sort of xlib6g-dummy for certain packages. Thanks. -- "3884d2bfa84fdce95c8d9170b36aa126" (a truly random sig)
