Another try ( was Re: the forest through the trees )

corey at corey at
Wed Jun 27 22:27:42 PDT 2001

Just before sending this I had a little light-bulb go off in my
head concerning the confusion and concerns we all seem to be having 
over the portability issue. 

I had in my mind only two forms of portability with ALFS:  

1: *backend* portabality between programming languages.
   ( I hope we can all agree that this certainly is not our aim )


2: *platform* portability between the backend and the xml spec
   ( which can be remedied with a flexible command element )

BUT, there's a third that I simply wasn't getting through my head,
that I think others have been talking about but not clearly stating:

3: *profile* portability between systems!

I certainly apologize for not catching this earlier, it could have
solved some confusion. I simply was not thinking in terms of a
person/company/whatever hoping to define a profile that anybody
*else* could use. This is deservant of it's own thread.

Later this evening I'll post another long-winded, rambling, opinionated
email to start discussion on that topic... (c8=

So does everyone agree that there are three types of portability
which ALFS can focus toward: backend, platform and profile? Is
there any others?

So read the following with a mind that I was not taking into account
#3, if anyone at all gets through the whole thing without their
eyes glazing over, I'll feel like it wasn't a wast of time.  (c8=


I hope I didn't get too overboard on this post - it's long, but I
really try stressing some points I've been trying to make that have
either been disagreed with, or that I perhaps merely have not 
clarified plainly enough. I'm thinking I just might have to provide 
some code and xml examples this weekend, so that I can visually explain 
where I'm coming from.

And upon Thursday of June 28, the illustrious Gerard Beekmans spake thusly...
> >   4) unless Linux-From-Scratch is intended to be built from VMS or some other
> would be nice

  Exactly - which is yet another reason for an extremely flexible method 
  for specifying commands and their parameters.  Which I'm getting the 
  impression Gerard - finally someone! - is agreeing with.

> >   5) 99% of the build and installation process occurs from within a makefile
> > which uses basic unix commands and the bourne shell. (refer to point 3)
> Ok, but who are we to decide that the basic unix utils are good enough
> for certain situations. 


> > In liew of the things, i think that the syntax for the pre & post install
> > commands should be something simple like:
> > 
> > <command>cp -R dir dest</command>
> > 
> > or if you want to go down the route of customization:
> > 
> > <!-- this user data entity could be in another doc -->
> > <user_data key="cp_options" val="-p"/>
> > 
> > <command>cp -R <user_data key="cp_options"> dir dest</command>
> Coming back to the statement made above and in my other email: you don't
> know for a fact that -R is available on the 'cp' you are assuming that
> somebody has. Parameters to cp and other basic utils may not change much
> or are the same on every system, but when it comes to other programs you
> don't want to rely on that. Perhaps you really need to use a non-gcc
> compiler that works pretty much the same but has a less parameters (say
> -malign_double doesn't exist, you could get an error when passing that,
> unless you describe it as something. Then you can decide whether you use
> it (by assigning a value to the description) or leave it blank if it's
> not supported on your choice of cc).

  Exactly why I've been lobying for my 'command' tag markup idea:

<command name='mv' src='/bin'>
  <opt name='-f' value=''>
  <opt name='' value='/foo'>
  <opt name='' value='/bar'>

  ( minus the 'id' attrs again )

  The *same* routine or method in the backend will now *always*
  be able to run the *exact* commands as specified by the *user*
  in *his* profile.  When the guy wants to use 'secure-mv' or
  what-not, then he merely changes his profile -- or yeah, he
  defines entities, so that he only needs to s/mv/secure-mv/
  in one place rather than many. 

  His profile, his choice, *his* work should he decide to change.

  Now we have this example that's been suggested:

<move src='/foo' dest='/bar'>

  So the parser returns 'move' to the backend. So now you need to 
  make an associative array that points "move" to 'mv' ( along with 
  'link' to 'ln', etc ). And of course now 'mv' has a different 
  command syntax than 'ln'... so *now* you *also* have to write
  friggin' if-else or whatever statements everywhere -- for every 
  command! That's insane.  Not to mention  you lose flexibility
  in the spec for the users - what if, as part of their '<postbuild>'
  profile for a certain package, we'll use the WindowMaker window
  manager, the user wants to run the 'wmaker.inst' script? Sorry
  chump, can't do it - nope, the ALFS does not allow that. So
  the poor dude has to do *two* things to facilitate for his 
  requirement - first he'll need to define a 'wmakerinst' element,
  and then he'll have to edit the backend source code so that
  it knows what to do with a 'wmakerinst' tag... sheesh, who the
  heck would want to work with a system like that?

  You cannot, 1 - have the XML heavily abstract your data and,
  2 - write the code to make guesses, assumptions and an indefinite 
  amount of workarounds - *either one* of those items are poor practice, 
  and I'm seeing people want to utilize *both*?  You'll end up 
  developing/designing your way right into a dead end, with nothing
  but an ugly mess to show for it.

  LFS is our guidebook on what constitutes a base, bare bones linux
  system, and what rudimentary packages and scripts, etc are required 
  to build that base. That's a HUGE groundwork which will be a major
  piece of the automated process in ALFS - but it should *not* be the
  basis by which we design the XML spec. Further, once we have designed
  the formal xml spec - the backend should *rarely ever have to change*,
  and should be fairly simple - the complexity goes into the XML
  profile, the backend merely does what the profile says to do.

  Basically: The 'alfs-sprofile' is an interface to modify the behavior
  the backend, which does all the labor of the automated installation
  and configuration of a customized linux environment.

> Perhaps I'm really overkilling this issue by wanting to be too versatile
> and modular and try to accomodate too much. 

  I, for one, don't think so - I think this is precisely how we
  should design ALFS from the start.  If we want this thing to
  be highly usefull for a huge variety of people, then we need
  to make sure that these people have the power and flexibility
  to do exactly what they want. Basically, I'm talking about
  designing a kind of "Meta-Linux" concept - can you imagine all
  the universities, companies, research programs, so on and so
  forth that would just *love* to be able to define and create
  their very own, niche specific linux environment?  With nothing
  more than an xml document or three?  If it requires that the
  XML spec be complex in places - so be it. If it requires a few
  days to a weeks initial effort - hell that's nothing. We design
  the spec to be able to basically do *anything* ( within reason ),
  and provide shortcuts via the use of defaults, entities, examples,
  and so on and so forth. Allowing the novice to get something
  defined real quick and easy, but allowing that university or
  that bioinformatics research group to really whip out something
  super custom, precise and extremely niche -- conforming to the
  XML spec that the ALFS contributors have designed and running 
  that off the backend application layer that we contributors have

  ( I *really* don't think we should focus on portability at the 
  *backend* -- we should decide what language we want to write it 
  in, and that's that.  If somebody decides for some freaky reason 
  to rewrite the backend in some other language - that's *their* 
  effort, not ours. I think perl or python fit perfectly with our 
  requirements. As far as portability on the *platform* end - that's
  instantly and elegantly acheivable through allowing the *users* 
  to specify the platform dependant tools and commands used in the 
  xml profile, as I've displayed with the 'command' element. )
  And so yeah - versatile and modular is killer; and it's going
  to require some serious flexibility and design -- ultimately
  that means we're going to need to be prepared for some complexity
  here guys.

> But if this is at all
> possible and easily done, why not. The less we force upon people, the
> better ALFS will be accepted and used I think.

  I totally agree.

  I stumbled on LFS by accident - I thought it was a super cool
  resource and was really impressed. Shortly thereafter I started
  thinking about how nice it would be for myself to automate my
  own custom linux - once I started thinking about that, I began
  thinking how cool it would be for *anyone* to automate there
  own custom linux. Then came xml of course, then came the backend
  planning, as well as some bootstrapping ideas - then I finally hit 
  on ALFS just recently and I thought - cool! this thing is already 
  being worked on! LFS set the precedent and has paved the way for 
  the next logical step, ALFS can prove to be a highly regarded and 
  well known/utilized project - so long as it is useful to a wide 
  audience. Why only go half way?


Unsubscribe: send email to alfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list