Helping Out [Was: Re: 2 New LFS Editors]

DJ Lucas dj at linuxfromscratch.org
Tue Sep 30 21:42:23 PDT 2008


Jeremy Huntwork wrote:
> Bruce Dubbs wrote:
>   
>> After that, we can address package management.  In the past there has been a 
>> fair amount of discussion about that, but we need to come to a decision on how 
>> to address it.
>>     
>
> Yeah, and that's part of the discussion I was trying to avoid again just 
> now. I rather doubt we'd be able to reach a consensus just yet. Perhaps 
> after the next release as you say.
>   
Probably after the next release, but I was driving down the road a few 
minutes ago, and I had a very simple idea on that.  It involves a little 
scripting, added to the book for each supported PM.  "supported PM" == 
"A developer is interested in maintaining it"  It would also require a 
repository of scripts/specs/conf files or whatever.  There could even be 
a common area for pre/post install scripts that are common to DESTDIR 
style PMs.  The book commands would simply be prefixed with the 
packaging script (which starts a shell with the proper environment 
setup) and then postfixed with an exit command.  Something like this:
------------------------------------------------------------------------------------------------------------------
PACKAGE="GLibC" VERSION="2.8-20080930" /tools/bin/lfsinst
--
./configure {...}
--
make
--
make install
--
exit 0
-------------------------------------------------------------------------------------------------------------------

The exit command breaks out of the shell that lfsinst provided us with, 
and then continues on to do the packaging and installation of the new 
package (or executes post-install commands for simple logging or tgz types).

Is something like that possible with say RPM or DEB packages?  Simple 
tar.gz packages and loggers I already know that it is very possible 
for...I'm doing something similar to capture the output of the commands 
in my homegrown lpackage ATM.

-- DJ Lucas

-- 
This message has been scanned for viruses and
dangerous content, and is believed to be clean.




More information about the lfs-dev mailing list