Dne 23.6.2017 v 10:57 Mark Wielaard napsal(a): > On Fri, 2017-06-23 at 10:11 +0200, Igor Gnatenko wrote: >> On Fri, 2017-06-23 at 09:57 +0200, Mark Wielaard wrote: >>> On Thu, 2017-06-22 at 17:15 +0200, Petr Šabata wrote: >>>> For the record, there appear to be only 25 binary packages that >>>> depend on /bin coreutils paths[1]; >>> I just took a quick look at the systemtap package. It has: >>> >>> # On RHEL[45], /bin/mktemp comes from the 'mktemp' package. On newer >>> # distributions, /bin/mktemp comes from the 'coreutils' package. To >>> # avoid a specific RHEL[45] Requires, we'll do a file-based require. >>> Requires: /bin/mktemp >>> >>> On RHEL5 the mktemp package only provides a /bin/mktemp and >>> no /usr/bin/mktemp. Now RHEL5 is fairly old and this Requires can be >>> changed for Fedora of course. But it might be that there are other >>> packages that share a spec file between RHEL and Fedora and have a >>> /bin >>> instead of /usr/bin Requires for this reason. >> RHEL[45] is dead, so feel free to drop this. Also polluting spec file >> with conditionals (or any other things) for unsupported/unrelated >> distros just create problems. > I won't argue about this particular case. RHEL4/5 is indeed pretty old > and I wouldn't mind dropping support for it. > > But in general I like it when my spec files "my spec files" - this is the main issue. All the conditionals are fine as long as the .spec files are really yours. During Ruby mass rebuilds, I have to deal with quite some packages which are not my and they even might be more or less abandoned. In this case the conditionals are troublesome, because I want to fix Rawhide, possibly rebase the package, but I don't really want to test if I break the package on other places (especially since EPEL packages might be created once and then never updated on purpose). Vít > just work for building > packages across Fedora/RHEL/SoftwareCollections even if that requires a > few conditionals. For example I maintain valgrind and have it setup so > that I can use the same spec file to build for "regular" Fedora, but > also do a copr build for older Fedora or CentOS [1]. And the same spec > file can be used to build the Developer Toolset software collection. It > makes sure that there is a way to get the latest upstream (and > backports) make it to different users. Which, in my experience, creates > a better package for everybody since bug fixes are shared. > > Cheers, > > Mark > > [1] > https://gnu.wildebeest.org/blog/mjw/2017/06/18/valgrind-3-13-0-for-fedora-and-centos/ > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
