On Fri, Feb 09, 2007 at 06:03:08PM -0500, Bill Nottingham wrote:
Axel Thimm (Axel.Thimm(a)ATrpms.net) said:
> Anyway the basic idea remains, we need something to define a very
> basic run time environment which all packages (but some bootstraping
> ones like glibc/setup/filesystem) may assume existing to not bloat the
> dependencies. Perhaps that's just coreutils and its dependencies,
> perhaps more.
... why?
Bill, who must have missed the first part of this...
My assumption is that there are many packages making use of coreutils
implicitely in their scriplets by using mv/rm/cp/touch etc w/o
Requires(xxx) on coreutils (or a virtual/file provides of it). I think
any package with a scriplet that doesn't chkconfig/service is most
probably using coreutils w/o pulling it in (e.g. like rpm).
The situation is saved by sibling packages like initscripts and/or the
kernel, e.g. the "bug" of missing coreutils dependencies goes unseen
as there are very few setups w/o initscripts/kernel already in
place. Still the packages are "broken" in the sense of not pulling in
their dependencies themselves (inlcuding recursive pulling) as
required by the guidelines.
So it's either
a) Axel's assumption wrong, there are only few packages doing
that - ignore him
b) A large number of packages violating guidelines, so we either
b1) fix all these packages
b2) adjust the guidelines to assume existence of coreutils for
99.9% of all packages (reverse exceptions would be
kernel/initscripts etc., something has to pull in coreutils
after all)
Depending on the actual number of these packages the order of action
is a) b1) b2), and I think the number will be large.
Maybe someone wants to script something to grep though all scriplets
for coreutils bits to get these numbers.
--
Axel.Thimm at
ATrpms.net