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