Re: IPFire Building Packages

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

On Sun, 2014-07-06 at 07:01 +0800, Ghislain Hachey wrote:
> On 7/5/14, 22:15, Michael Tremer wrote:
> >> * Yet some other dependencies are typically downloaded and compiled as
> >> >part of the make step of the package build. My understanding of why it
> >> >is this way is because of the tight integration between the software and
> >> >those dependencies. My question is this: is it necessary to create
> >> >pakfire packages for the ones usually downloaded and compiled in make
> >> >process, or is it ok to let the make process take care of it? One more
> >> >thing worth mentioning is that some of those packages automatically
> >> >downloaded and compiled are available in IPFire (like rrdtool). Will
> >> >that create conflicts or can it safely coexists?
> > I don't really know what you want to know here. Tools like rrdtool are
> > not packaged because they belong to the core system which is not managed
> > by pakfire. pakfire only manages add-ons.
> 
> Thanks, great. Yes that mostly covers everything. Except the above. What 
> I meant is that the software I am trying to package packages its own 
> rrdtool, JITLua, amongst a few others. They are dependencies but 
> installed by the make step in a normal build process (also compiling 
> those from source). Now I know that, for example, rrdtool is already 
> part of IPFire and want to know if it will be ok to have two copies 
> installed (one by pakfire and the other by the make step of the software 
> I am packaging).

That's what we call bundled packages (very often libraries) and which
are extremely discouraged. The problem that comes with that is that when
a component gets updated to resolve a certain issue this problem is
still in the twenty other copies of the same software. Imagine that for
things like Heartbleed. It also consumes space, increases the build time
and so on.

You should use the provided versions of those tools and libraries or
modify them if that is required. All other components that are missing
should be created as individual packages.

> 
> Either way, I think its best I just give it a go and come back here with 
> more specifics.
> 
> Thanks,
> 
> --
> GH
>