util-linux missing from build root

[Michael Schwendt]

On Thu, 30 Aug 2007 12:56:40 +0200 (CEST), Nicolas Mailhot wrote:

> 
> Le Jeu 30 août 2007 11:50, Michael Schwendt a écrit :
> > On Thu, 30 Aug 2007 11:41:11 +0200 (CEST), Nicolas Mailhot wrote:
> >
> >>
> >> Le Jeu 30 août 2007 11:34, Michael Schwendt a écrit :
> >>
> >> >  From the perspective of Joe Packager, if you need a program/file,
> >> you
> >> > hunt it down, "rpm -qf" or "repoquery --whatprovides" it, and add
> >> the
> >> > found package name as a BR.
> >>
> >> Or you do which foo and add this BR (a lot simpler, faster and more
> >> reliable)
> >
> > No, "rpm -qf $(which foo)" to be precise, since it returns only a path
> > and not a package name.
> 
> Which was exactly the point. When a script/Makefile requires a
> particular command, and this command has multiple implementation or is
> provided by a package which naming stability is dubious, BR/R-ing the
> filename and not the package name is the right thing.
> 
> If package naming and package repartition was stable or reliable we'd
> be requiring perl package names instead of the stuff inside.

There is a big difference between the perl(Foo::Module) virtual provides
and requiring full paths to file names.

/usr/bin/foo can move to /usr/local/bin/foo if you don't require
/usr/bin/foo explicitly anywhere. And this example works for other
paths, too.

Requiring file paths is dangerous when conflicts between packages
are permitted and shortest pkg name wins in yum depsolving. Enjoy
https://bugzilla.redhat.com/208781 for a utility pkg that conflicts
with give other pkgs.
 
> When you know the exact R/BR your package needs it's totaly insane to
> go through the package name indirection.
> 

Except that loading and parsing the metadata filelists slows down
the depsolver a lot, and requiring a single file does only guarantee
that you get the single file -- if you need many more files, would
you require each of them explicitly?

Anyway, we're drifting off, IMO.