util-linux missing from build root

[Michael Schwendt]

On Thu, 30 Aug 2007 15:32:16 +0200 (CEST), Nicolas Mailhot wrote:

> 
> Le Jeu 30 août 2007 15:10, Michael Schwendt a écrit :
> > On Thu, 30 Aug 2007 14:13:44 +0200 (CEST), Nicolas Mailhot wrote:
> >
> >> > /usr/bin/foo can move to /usr/local/bin/foo
> >>
> >> Not in our packaging.
> >
> > But making it impossible can't be the goal either.
> 
> We're not "making it impossible", anymore than naming a package some
> way "makes it impossible" for other entities to make a different
> choice. you can put a symlink in /usr/bin/ just like you can put some
> fugly compat goo inside your third-party rpm

Not if /usr/local is installed from tarballs instead of from rpms.
That won't fill the RPM db.
 
> (also a lot of this stuff can not be moved because of LSB anyway)

Do we need explicit path-based R/BR for programs covered by the LSB? =:-O
 
> >> > Requiring file paths is dangerous when conflicts between packages
> >> > are permitted and shortest pkg name wins in yum depsolving.
> >>
> >> So? You can make the same argument for perl modules, library names,
> >> etc (with more reason as semi-compatible forks are legion)
> >
> > Sure. Just that file path Requires aren't automatic, except for script
> > interpreters.
> 
> That does not make autoprovide name collisions any less dangerous than
> filename collisions

Every file in $PATH is automatically provided in the file lists.
Compare that with a Perl source file that must do something special
to create a module that results in a virtual Provides.
 

> >> > 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?
> >>
> >> If you need many commands that have no special reason to be in a
> >> single package and in fact migrate from package to package requiring
> >> them instead of putting the current container name is the right
> >> thing.
> >>
> >> If you need many commands that are closely associated requiring just
> >> one of them will pull the others just as effectively as the package
> >> name.
> >
> > The guidelines talk about _guarantees_, though. The probability that
> > "Requires: /bin/mount" pulls in related tools via util-linux is
> > high but no guarantee. Just recently, /usr/bin/setarch got moved from
> > one package to another, which then got renamed.
> 
> This is a perfect example of why requiring the container instead of
> the actual stuff you need is bad. mount and setarch are not closely
> related, they just happened to be bundled together for some time.

It demonstrates why you would rather need to require lots of single
files, because you cannot rely on /bin/mount being bundled with
/bin/umount and more likely not being bundled with /sbin/losetup
either. Same for cpp, gcc, ld, strip, ...

A well-defined base environment that need not be specified as R/BR
is superior.