util-linux missing from build root

[Nicolas Mailhot]

Le Jeu 30 août 2007 13:13, Michael Schwendt a écrit :

> 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

Not in our packaging. It *can* move from /usr/bin to /bin but that's
pretty unusual.

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

The vast majority of the stuff people are clamouring for in buildroots
are small commands in /usr/bin and /bin.

Those do *not* wander in the filesystem. Too many scripts that
hardcode their path would break.

I've almost never seen a file dep of this kind be broken by filesystem
layout changes, and when it did happen it *always* happened with
massive package name shuffling that would have required fixing if a
rpm name had been used instead (immediate or delayed fixing, depending
on the fake provides the new package exposed if it was a 1:1 change)

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

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

That's a tooling problem. Since you bring it up commands that end up
in everyone's default $PATH should end up in autoprovides not
filelists IMHO (most of them have a lot more reason to end up there
than some of the fluff the existing autoprovides scripts unearth,
those who don't usually have no place in $PATH either, and by not
making them explicit provides they slip through conflict checking)

> 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.

If you need many commands that are closely associated and specific to
a particular implementation of a toolset requiring the toolset name is
the right thing. This is not the common case though.

However for common commands which have many implementations build
scripts can handle any one of them, and depending on the package name
of the implementation Fedora currently favours buys you nothing and
results in broken builds after a few years.

-- 
Nicolas Mailhot