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. Since we package for specific releases of a distribution, I'd rather recommend more use of the %check section in spec files at build-time. > > 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. We don't have virtual Provides for executables in distribution $PATH, e.g. exec(grep) > > 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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
