Many people do that and find it convenient, but I don't see how maintaining the same SPEC file for different distros is less of a maintenance burden than having a different SPEC for each distro/branch you want to support. And clearly, Fedora has diverged too much from any RHEL/epel buildroots currently, so keeping the same SPEC is even harder, not mentioning of course that it's a recipe for disaster for automation tools like rebase-helper or things like targeted mass rebuilds (e.g. when python/ruby/perl are rebased so all the respective packages have to be rebuilt) etc. Charalampos Stratakis Associate Software Engineer Python Maintenance Team, Red Hat ----- Original Message ----- From: "Mark Wielaard" <mjw@xxxxxxxxxxxxxxxxx> To: "Igor Gnatenko" <ignatenkobrain@xxxxxxxxxxxxxxxxx> Cc: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> Sent: Friday, June 23, 2017 10:57:11 AM Subject: Re: coreutils /bin file dependencies 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 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
