Re: Package Question

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

 



On Mon, Jan 8, 2018 at 3:38 PM, Fernando Nasser <fnasser@xxxxxxxxxx> wrote:
> On 2018-01-08 3:07 PM, Nico Kadel-Garcia wrote:
>>
>> On Mon, Jan 8, 2018 at 2:32 PM, Fernando Nasser <fnasser@xxxxxxxxxx>
>> 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@xxxxxxxxxxxxxxxxxxxxxxx
>> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
>
>
>
_______________________________________________
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