Re: Future automation possibilities

"Bruce Dubbs" ([email protected] via alfs-discuss Mailing List) <[email protected]>
Newsgroups gmane.linux.lfs.automated
Message-ID <[email protected]>
On 9/30/22 17:51, Craig Jackson ([email protected] via alfs-discuss Mailing 
List) wrote:
> As someone who has attempted to implement this same concept in Python of reading the 
> book XML and running commands as needed, It was incredibly difficult trying to 
> triangulate the XML tree of the book to identify some sort of consistent pattern to 
> use without also creating a lookup table for certain chapters which breaks forward 
> compatibility when the book structure changes.  I understand that the book's XML is 
> ideal for the context of publishing a document, so hesitation to change this is 
> warranted.  But I wonder if a compromise would be for Jeremy or a delegate to provide 
> a set of tags to the LFS dev team that would help to identify which type of text box 
> is being used (run in chroot, run as lfs user, etc.) to provide that metadata for 
> automation.

There are several issues that make automating LFS and BLFS difficult.  It's not the 
language, but the algorithms necessary.

LFS is relatively straight forward.  The book is linear.  The main issue is whether 
you want to build the System V or systemd versions of the book.

The real problem is automating BLFS.  First you have to decide what packages you want 
to install.  That is not really a trivial problem.  Second, we have dependencies 
broken up as require, recommended, and optional.  We generally consider recommended 
dependencies as required unless you really know what you are doing and why you might 
want to skip some of them.

Then there is the problem when we get into circular dependencies.  Those really have 
to be treated individually,

Finally we get to the issue of optional dependencies.  I know of no one else that 
lists some dependencies as optional.  Generally others treat all dependencies as 
required.  That in turn increases the circular dependency problem by an order of 
magnitude.

I do not know of a way to treat all of that algorithmically.

And then there is the additional issue of configuration.  Many of the BLFS packages 
have configuration sections that may depend on user preferences.  How should that be 
handled?

Speaking of configuration and going back to LFS, how should the kernel be configured? 
  That is certainly not trivial.  I suppose you could just use 'make allmodconfig' 
but that seems very unsatisfying to me.

To me, the current jhalfs does what I need, but I'm sure it can be improved.  However 
the issues above need to be addressed to decide what is needed and then a way to 
implement those needs requires an integrated design approach.

   -- Bruce

-- 
http://lists.linuxfromscratch.org/sympa/info/alfs-discuss
Unsubscribe: See the above information page
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.