syntax, portabilities, and the principle of least privilege

Chris jcore at
Tue Jun 26 13:27:34 PDT 2001

On Mon, Jun 25, 2001 at 04:03:02PM +0800, corey at wrote:
> <command id='1' name='mv' src='/bin'>
>   <opt id='1' name='-f' value=''>
>   <opt id='2' name='' value='/foo'>
>   <opt id='3' name='' value='/bar'>
> </command

Ok, I admit, there was a heck of a lot more said than this, but I think this captures the points I want to make the best.  I'll try to break this down into a logical structure.

First, alfs is going to need a TON of package descriptions to be useful to anyone.  I've recently been working with gentoo (very similar to alfs, with a somewhat different approach), and installing a package from source outside of the gentoo ebuild tool can really throw off your distribution.  Luckily, the package description files are short and easy to write (easy enough for almost anyone to contribute one).  Having said that...

...We come to the "portability" issue, which isn't so much a portability issue as it is an abstraction issue.  With ALFS we're trying to get at least one level of indirection away from the shell.  Not only does abstraction keep our package descriptions smaller (see above paragraph), but it keeps them from being dependent on a certain shell (who says ALFS will always be using shell commands?).  Now, the dangers with doing this are loss of freedom (and being GNU/Linux/LFS guys, I know we all fear that), but the benefits are more "portable" (across platform and ALFS implementations) definitions that are less likely to need to be rewritten.  We also get the advantages of data hiding and the principle of least privilege...

...Which takes the absolutes out of the package descriptions.  I propose that we place most of the base information into the system description (hopefully an XML Schema or inheritance of Schemas), allow local modifications in the package description, and implement everything with the ALFS implementation.  I know that's not a very clear way of saying it, so...

<!-- uses all defaults, including flags specified in the system Schema -->
<configure />

<!-- uses all flags specified in the system Schema and adds a configure option "prefix" which takes of the value of OPTDIR (perhaps /opt or /usr/local, depending on the system description) -->
<configure prefix="%optdir;/hello" />

<!-- allows for extra configure options that aren't given in the system Schema, and also specifies a directory to run the configure from -->
<configure add="gl" add="vorbis">xmms-build</configure>

What we've got to remember is that "we" are not going to be the only ones writing package descriptions.  These will probably get contributed by many different people who aren't familiar with ALFS.  I would really suck to have a nice system built, decide to install some new package, and then the package writes tons of files into your /usr/bin directory (which is low on space, as compared to your /opt partition) because the author didn't know where it really should have gone (which the author shouldn't know anyway!).

I wish I had a Schema written to back this up for you guys (I'm planning on one soon).

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