xlib6g and xfree86-common

[Santiago Vila <sanvila@unex.es>]

[ 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)