Re: coreutils /bin file dependencies

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Friday, June 23, 2017 10:57:11 Mark Wielaard wrote:
> 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.

I really appreciate that you take this approach.  It helps me a lot when I 
debug something as I often want to build a Fedora package on RHEL or vice 
versa.  However, it is not what Petr's question was about...

He is not asking whether we should remove the /bin/* provides from the 
coreutils package.  He is asking whether we should now introduce them into
the coreutils-single package, too.

If you are experimenting with packages mixed across distributions, it is 
unlikely that you have coreutils-single installed.  The coreutils-single 
package is intended for use in Fedora-based containers where you have up2date 
version of software.  On regular installations of Fedora, users will continue 
to use the coreutils package, which already has these /bin/* provides.

Kamil

> Cheers,
> 
> Mark
> 
> [1]
> https://gnu.wildebeest.org/blog/mjw/2017/06/18/valgrind-3-13-0-for-fedora-an
> d-centos/
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux