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 (also a lot of this stuff can not be moved because of LSB anyway) >> > 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 > We don't have virtual Provides for executables in distribution $PATH, > e.g. exec(grep) More the pity >> > 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: /usr/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. Regards, -- Nicolas Mailhot -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
