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