IPFire Building Packages

[Ghislain Hachey <ghachey.lists@gmail.com>]

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

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

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?
* Should a make test step (if there is one) be included in the lfs 
definition?
* 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 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.

Regards.

-- 
GH