Project scope ?

Jay Bennie jay at
Tue Nov 13 08:54:41 PST 2001

As an extension to the dtd can we have <aoptions></aoptions>

I have an idea for a GUI tool that will need to see all the options available for the package, in order to select the <options> for the profile. 

The tool will provide an interface to graphically modify/create a profile, and I feel that keeping the data in the profile is preferable to using some other mechanism. 

As I mentioned this is still just a concept idea, any thoughts. - PS I'm slowly generating a spec for review of this suite of tools, I hope to get it published in the next week or so. 
in brief 
{my aim is to construct a suite of software that can 

a. be deployed via a bootable cd (assume network access to get src updates) 
b  the tools allow the creation of a known build env (I.e set up disks, run basic kernel with inet connection to retrieve source from a server)/ create a dedicated repository/ env building and deployment server. 
c. tools to create and manage package and dist profiles
d. tools to manage a centralised src repository
e. tools to maintain a network (I.e synchronise, workstation envs from master envs. controlling each instance with a profile rather than a boot img, this way a modification of a profile, would result in a workstation auto updating from the repository)

the aim is to make this suite into the holy grail of "from src" package deployment in a network env. 
with both comprehensive prompt and GUI interfaces.

The other point that I wanted to ask was, do you know of any other projects with similar goals. There would be little point in rebuilding the wheel. 

Thanks J

----- Original Message ----- 
  From: Neven Has 
  To: alfs-discuss at 
  Sent: Tuesday, November 13, 2001 3:45 PM
  Subject: Re: new dtd

  On Mon, Nov 12, 2001 at 11:28:12PM +0000, Mark Ellis wrote:
  > Time to come up with an element name then eh ? <options> isn't bad, or
  > <flags> maybe ? And what values ? "Force" for link, copy, and move
  > obviously, can't decide whether link type would be better left by itself or
  > put with the other options. Possibly best left separate as a type should
  > really be mandatory, not optional, but see the answer below for more on
  > this.

  I think it's best that we use the same names that GNU programs use.
  It will be easier to remember them. For LFS profiles, we would need:



      <options>force archive</options>

  That's some minimum that LFS profiles use, we could add more latter.

  > Links must have a type, whether this is explicitly declared or a default.
  > These types are also specifically defined, ie hard or symbolic. Element
  > content can be absolutely anything, not actually a problem 'cos we have
  > backend validation, user docs (ok in an ideal world :) ), but the xml says
  > nothing about what is allowed. In an attribute you can specify what the
  > possible values are and what the default should be. Again unless you are
  > validating the xml you gain nothing concrete but there is built in
  > documentation.

  I never played much with DTDs, so I didn't think about that (specifying
  possible values for attributes) at all. That seems like a good reason
  for moving it back to attribute.

  > Conversely, chroot dir can be essentially anything, and to me seems more
  > like a "thing" than a "property" if you see what i mean.
  > So i really like link type as an attribute, chroot dir seems more like an
  > element but really doesn't matter either way, so i guess if we shouldn't
  > get any parse errors, go for both as attribs.

  I know that you mean, but when I write "<dir>&LFS;</dir>" after <chroot> and
  just before some <package> in a profile, it doesn't seem natural to me at all.

  But as you say, it doesn't really matter in the end, so just put it where
  ever you want when you wrap up DTD.

  > <base> has grown on me a bit, how about <base_dir>, or <basedir> for easier
  > typing, bit more explicit, or does that sound too much like a pseudo
  > filesystem root ?

  I'm not very good in naming things, so I'm tempted to allow and implement all
  those names. ;) I'll just quietly escape from this discussion. :)

  What happened to all our profile writers?
  Don't they care about stuff like this at all?


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the alfs-discuss mailing list