Andreas Metzler wrote: > Frank Küster wrote: > > in a package that I maintain (sponsored by a DD), I use a call to > > stat. In sarge, /usr/bin/stat is in coreutils - of course I don't need a > > dependency on that. However, in woody stat was in a separate > > package. Usually packages keep really old versioned dependencies - this > > might be important for upgrades, and it's friendly for backporters.
I just ran into almost the same case with a local meta package that I maintain. So this has suddenly become pertinent for me as well. > > If coreutils wouldn't be of priority required, I would just add > > "coreutils | stat" to the dependencies. What should I do in this case? > > Stat was in coreutils from the first time it appeared in Debian, so a > > versioned Depends: wouldn't make any sense (except that it makes lintian > > and linda be quiet...) > > I don't have a sid system at hand, but doesn't coreutils > Provides/Replaces stat? Is there any reason that stat was removed from sarge? Since coreutils has subsumed 'stat' shouldn't 'coreutils' create an empty package 'stat' for the transition? This would be the same as with shellutils, fileutils, textutils. It can then be removed at the next release along with those other three. How I 'stat' different than the other three? As an alternative could a standalone stat package could be created which depends upon coreutils and conflicts with older stat packages? Bob
pgp00000.pgp
Description: PGP signature
