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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
