Profile generation (XML DocBook => ???)
persistent.spam at thack.org
Wed Mar 8 03:03:16 PST 2006
On Tue, Mar 07, 2006 at 05:20:42PM -0500, Kendrick wrote:
> 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.
> 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 a good idea and can be implemented to some extent, but everything
cannot be selected from the UI. For example I don't feel that we should have
checkboxes or anything predefined for say --disable-static and
--disable-dependency-tracking. Also we should not provide input fields for
STAGE1_CFLAGS or BOOT_CFLAGS for GCC compilation.
> 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.
But IMHO the alfs tool should be generic and it should not know anything about
LFS, BLFS, or CLFS more than it knows about HLFS. It should only know about
packages and of some extra phases needed for configuration or building
environment adjustment. Then the user loads profiles and selects what to
bulid, and generally one would build everything under LFS/CLFS/HLFS.
The profiles must be human readable and writable to allow them to be easily
customised. Doing otherwise would be against the LFS idiom.
> 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.
Or too easy for BLFS: packages which are just CMMI don't need an entry there,
but alfsers will likely accept ready-made profiles for those.
> 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.
This is not convenient when building systems for about 100 servers, unless
they are completely identical. However, this does not mean that UI should not
be utilised to make building LFS/BLFS easier, but this should be done within
certain limits. We should not have BLFS profiles which take into account all
possible installation alternatives, since I still feel that BLFS profiles
should be generated from the book, otherwise they require separate
maintainance, which is at present killing nALFS.
More information about the alfs-discuss