Profile generation (XML DocBook => ???)

Kendrick alfs at
Tue Mar 7 14:20:42 PST 2006

I dont know how the blfs book could be just parsed and run.  Some
seperation tags might be use full.  There are so many packages in there
that 1) the user isnt going to want 2) needx extra configuration that
cant just be automagicly done for the user.  example is a fair ammount
of us will want the packages installed in different locations then the
book.  I have been thinking about how this could be done properly and
with enough flexability that it will be usefull to alot of people.  I
would like to get some thoughs and comments about how this needs to be
done (pokes Gerard).  Here is what I have come up with.

when you install MS office or what ever you have a multi tree area.  you
select word then from the branches you instal filters and languages
etc.  then the next tree is excell etc...

in my mind somthing similer to nALFS's curses tree would be great  for
the majority of selecting from the user side.  but we will also need to
have areas to input text for optimisations and paths.   I dont know that
we can exactly just pull from the blfs book to get the blfs part done. 
I would suggest that that be a starting point for the profile snipit for
that item.  then add in options like the check box for adding
--with-mysql   or, check box --sysconfdir=[Textbox]   
This is all user interface thought, how ever I feal it also bares alot
on how we handle the Blfs portion of profile/compile work.  I dont see
any problems with lfs being  directly parsed from the book and make a
profile hunk for lfs/clfs/hlfs.  When you start the program you just
select one of those 3 from the base section  the UI applys any nessasary
"filter/modification"  to the blfs begennings and you go through and
select things from there.  My use of "filter/modification" is for
example --enable-pax and other hardened options that you would need
enabled.  Since in non pax systems the options are not always there, 
the  selection of the hlfs base package would set a mark --enable-pax 
&&  enable pax sed commands. The blfs side would now have areas where if
pax is aready properly supported a check box for enableing it in the
package.  If there is a special blfs sed/command for enabling pax ( i
think just a fiew packages are like this) it would either get
automaticly added to the profile or a new checkbox marked would show up. 

Now for how the "profile" needs handeling.  This is just speculative
thought.  I could almost see it being handled like CPAN's.  There is a
list of what packages we already have a build process for from the
book's.  you either grab them all before hand or  posibly  live as you
go along.  If you create a new one you  post it  to the  alfs  profile 
area and it gets looked at and  added to the repository.  Especialy
helpfull for programs that need specific modifications for lfs but may
not be  popular enough for the book yet.  Once the bits of blfs are
downloaded you start up your client or if its built in you start
checking off what else you want on your system after you mark the lfs
base you want it made from.  mark off all options that aply for you the
system/systems that will be building it then tell the compile systems to
get to work.  This way the end user shouldent have to edit any profile
just chek off options needed for their build.

I could see some new tags being used for seperation of commands  when
trying to use a base other then lfs.  the lfs tags would be the default
used, if theres a hlfs patch for the package it would use the hlfs tags
during a hlfs build.  if there were no hlfs tags for the blfs package it
would use the default of lfs tags. 

Thats just my nickle and dime's worth ;)

Tapio Kelloniemi wrote:

>In BLFS, however, we have many such commands, for example commands in sections "Additional X Window System Configuration" and "X Window System Components" should never be executed

More information about the alfs-discuss mailing list