On Mon, Jan 8, 2018 at 3:38 PM, Fernando Nasser <fnas...@redhat.com> wrote: > On 2018-01-08 3:07 PM, Nico Kadel-Garcia wrote: >> >> On Mon, Jan 8, 2018 at 2:32 PM, Fernando Nasser <fnas...@redhat.com> >> wrote: >>> >>> On 2018-01-08 12:21 PM, Steve Dickson wrote: >>>> >>>> Hello, >>>> >>>> Is it a problem for a package to pull from two different >>>> upstream tar balls? Basically have >>>> >>>> Source0: http://server.com/package1/package1.tar >>>> Source1: http://server.com/package2/package2.tar >> >> It happens all the time. Subversion used to do this a lot, when the >> requirement for the "swig" library was more recent than what was in >> Fedora. It also happens quite a lot for RHEL and EPEL packages, where >> the necessary versions of various libraries may conflict with the >> stable, standard library used by other tools. > > > Hum... not sure if this was good form. An important security fix may fail > to be applied to this "hidden" library for one thing.
This is absolutely true. It's especially been necessary for various EPEL packages, which may have requirements of more recent libraries. > This is supposed to be handled by having a versioned package for the > alternative library version that could then be used by this package (as > opposed as the default Fedora version of it). Yeah. It can be awkward to maintain, and the potential requirement is precisely why the "%setup" macro in RPM is designed to support the extraction of multiple tarballs in an arbitrary build layout: because some packages are published as a set of multiple tarballs. "git", for example, has often been built from the distinct git, git-html, and git-manpages tarballs from upstream in order to avoid having to build those other components and require all the build tools for documentation on the local RPM build environment. Been there, done that, publish tools for CentOS 6 and 7 for git-2.15 at https://github.com/nkadel/git215-srpm/blob/master/git215.spec "texlive" is a better example, since it has so many source tarballs for different fonts from upstreamy. I count roughly 7000 distinct Source tarballs listed in texlive.spec, Those *are* the Fedora system component for those fonts, so it's a better example of where the usage or multiple tarballs makes great sense sense. Building distinct, internal libraries has been unusual to need directly for Fedora, since Fedora tends to be near the bleeding edge of software releases. But it's certainly happened on occasion, especially if software needs to be backported to EPEL for RHEL and CentOS use, or for for older versions of Fedora. > This has similar problems as using the Maven shadow plugin in Fedora Java > builds (which is AFAIK also discouraged). > > --Fernando > > > >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org > > > _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
