automated profile generation

Reinhard bookreader at gmx.com
Wed Mar 24 01:43:54 PST 2004


Thank you Kevin, for your attention
and sorry for the delay in my anwer.
I was short of time, cause I worked on support for newxml.

On Saturday 20 March 2004 16:08, Kevin P. Fleming wrote:
> Reinhard wrote:
> > By the way - do you know, how to do command chaining in profile syntax?
> > (samples from cvs-version of BLFS)
> > i.e. apache:
> > sed -i -e "s%User nobody%User apache%" -e "s%^Group #-1%Group apache%"
> > /etc/ apache/httpd.conf
> >
> > i.e. exim:
> > sed -e 's/^BIN_DIR.*$/BIN_DIRECTORY=\/usr\/sbin/' src/EDITME | sed -e 's/
> > ^CONF.*$/CONFIGURE_FILE=\/etc\/exim.conf/' | sed -e 's/^EXIM_USER.*$/
> > EXIM_USER=exim/' | sed -e 's/^EXIM_MONITOR/#EXIM_MONITOR/' >
> > Local/Makefile
>
> There are some examples of this in the official LFS profile. As it
> stands today you must supply all of this to an <execute> element, as a
> string of <param> elements.
>
> In the next version of nALFS (and the next DTD version) <execute> will
> support being supplied a script so this will be much easier.

Just to ensure, that I got it right:

<search_replace> is (stands today) only usable for 'sed -i -e ...',
cause it only has a filename param and find/replace are singletons.

Do you know, are there plans to extend this to support i.e. <infile> and 
<outfile> or to enable multiple commands, you could i.e. allow following 
syntax:

<infile> a file </infile>
<outfile> a file </outfile>
<job>
	<find>pattern</find>
	<replace>text</replace>
</job>
<job>
	<find>another pattern</find>
	<replace>another text</replace>
</job>

What do you think about that?

Using the execute pattern, I'm now at the point where I could generate all 
profiles from lfs and blfs using oldxml and newxml.
I gonna check the generated results against the official profiles - but that 
may take some time.

I read, that now the profiles where placed in cvs. 
Do you already have scripts to generate them?
If not, are you interested in such scripts?

Or what do you think about integration of some of that features in nALFS?

At the moment, all is written in perl, but I think it could be ported to C or 
C++ or whatever you like.

Don't know, if I'm wrong, but I think the editors of the (blfs-)book have 
little interest on fixing the dependencies.

What do you think about adding the dependencies as diffs to the profiles?
So you could generate the profiles, apply the patches and have a complete 
information-base at your fingertips.


Kind regards

Reinhard




More information about the alfs-discuss mailing list