Re: IPFire Building Packages

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

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

Hello,

I am not sure if I completely understood what you are asking, but I will
have a try at answering them. If something is still not clear, please
try to give some more detail...

I also assume that we are talking about IPFire 2 here.

On Sat, 2014-07-05 at 17:45 +0800, Ghislain Hachey wrote:
> Hi,
> 
> I started building my own packages for IPFire and could use a little 
> guidance.
> 
> The package I want to add to pakfire has a number of dependencies. It 
> goes like this:
> 
> * Several are already part of IPFire (libpcap, libtool, autoconf tools, 
> and some more). I don't need to do anything in most cases, but what if 
> my package requires a newer version than the one available in pakfire?

In that case, you should update them and send us the patch. Just make
sure that the new version is completely backwards-compatible and does
not break anything in the build process or at run time. Sometimes we
keep older versions of the libraries around (check out the lfs/*-compat
files for an example).

> * At least one dependency is not already available (it's redis). I 
> already created a pakfire package for this one and tested it on my own 
> IPFire box, seems to work.

Great.

> * 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.

You can use those things if they are around and you can assume that they
are always there when they are part of the core system. Otherwise just
add them as a dependency.

If you are adding some things that are not already there, please create
an extra file (= package) in the lfs/ directory. Don't build them all in
one step.

> Some more questions:
> 
> * When install my redis pakfire package I get the message 
> "/opt/pakfire/lib/functions.sh: line 91: /etc/init.d/: is a directory", 
> why is that?

This is because the install.sh script requires some environment
variables to be set which is not the case when you execute it manually.
pakfire will do that.

> * Should a make test step (if there is one) be included in the lfs 
> definition?

You may add the commands but please comment them out. This is a huge
problem of the build system of IPFire 2 that you need to rebuild the
entire distribution from scratch every time you change some tiny bit. So
that would make the build process even longer and basically not feasible
on architectures like ARM. In IPFire 3 we require to execute the
testsuite when existant.

> * Again in the lfs definition, what's the difference between using 
> "install -v -m644 $(DIR_SRC)/config/redis/redis.conf 
> /etc/redis/redis.conf" and "cp $(DIR_SRC)/config/redis/redis.conf 
> /etc/redis/redis.conf". Which one should I use? Which one should I use 
> for initscripts? I've looked at several other lfs files but seems things 
> are done slightly differently which makes it a bit harder to understand.

I prefer the install command which ensures that permissions and a
possible ownership of the files are correct. In the end it is not
important which one to use really.

> * I don't see anywhere in the lfs definition how I would run a process 
> as a new non-root user. I see many add-ons runb as root which is not as 
> secure as it could be. What is best practice here and how to go about it.

Most of the add-on processes are executed as root and drop their
privileges shortly after startup. openvpn for example needs to bind to a
privileged port and add routes which requires root privileges. This is
also the preferred way to do it.

In the case that your software does not support this you may either
patch the software or use sudo.

> 
> Regards.
> 

Hope this helps. If not, please feel free to post any more questions and
even include some files or parts of the files.

Best,
-Michael