Alfs Update - have time before reading.........

Bryan Dumm bdumm at
Tue Dec 26 21:37:37 PST 2000


> Sure, this can wait.
> Tags themselves are important, what's inside them is not so much. :)

Great, unless Gerard has any other reasons we will hold @ 2.4.3 for a
while. We'll have to update the profile we have now, but I don't think
the 2.4.2->2.4.3 changes were that big.

> > I think if we divide it up by chapters it will be easier to
> > debug, and we can always include a "complete profile".
> _Lot_ easier to debug.

Agreed, unless Gerard/others have a complaint I think we should
do it this way. Chaps and a main profile. 

> Yes, this is good, and <system_command> should have "dir" attribute too
> (Gerard mentioned this below for patching).


> How will the backend and the frontend communicate? I remember some
> discussion on mailing lists (even alfs-ips was created?), but not much.
> It can be simple reading of stdout (xml based like you said) from the
> backend by the frontend, or something better?

Well thats still up in the air, but the two things I think that would be 
important would be

1. the messages are all in some xml format. 
2. we allow for some ability to add infrastructure later on
    (I am think authentication/authorization type features that
     might depend on the front-back end setup.....)

Other than the authorization/authnetication and I guess encruption type
issues, the front/backends should be able to parse and deal with the
xml message itself.... Also we might want to look @ some 
more as although it is based on IM type clients, they are providing 
such a messaging infrastructure that we can probably use, is already
more robust, gives us their extra IM/other features, etc......

> Somebody should propose the format of these messages, like:
> <error type="fatal" line="103" exit_code="256" msg="Installing of ...
> failed"> <system_command param1="install">make</system_command>
> </error>
> or something like that?

Yes this is a good idea, and I think we should go breath some life into
the ALFS-IPC list. Neven do you want to do the initial post, and maybe
do a smaller cross post to alfs-discuss, lfs-discuss(?)? Something to 
breath life into it? Gerard, suggestions?

> Sound interesting. I just wish I know what that infosystem is. :)
> I think I'll have to reread some mailing lists ...

Well go take a look at the general descriptions of something like XSLT
and how we can use it to make xml act as a database on a system locally.
Also think about having say a cpan type setup where you can always get
a local mirror that has all kinds of program profiles in them, maybe even 
the program tarballs themselves. Dunno if we need to re-create some of
these already established ftp archives. Maybe add some xml messages
between the infosystem and someone's alfs to figure out details, profile(s)
needed etc. Start throwing in LFS-hints and other such things to add to 
the expierence, make it work right or manually etc. 

More ideas?

> I actually started coding this since I think it's a good idea and since you
> forgot to attach your code and I had nothing better to do. ;)
> I can send it, although it's not much and it creates a very simple profile
> without inspecting the "./configure --help" output.
> It just looks whether "configure" and/or "Makefile" exist.

Heh, nice. Thanks, I had not done it. Just got the idea....
Send it whenever. 

> > I have assumed this in my work. I hope it wasn't in vain. else just let
> > me know and I will change it again. But that was the whole point of those
> > vafs in the <package> tag so they can be used in the commands in that
> > section.
> I'm not sure that this works. I tried it, and was getting "undefined
> entity" error message from the parser, so I suppose "&var;" can only be
> used when defined as an entity and not as a tag attribute.
> I searched some docs and XML specs on this and didn't find anything.

I will test and verify this as I get back to alfs, just now getting back and
catching up.

<chroot/package location mess snipped>
> But like I said, if somebody has a better idea ... I don't :)

I'll put some more creative energy into it. :)

/me hopes he doesn't draw a blank...

> For patching, we will always use "patch" (system command) so I don't see
> the need for the new tag. Of course it can be useful for the
> backend/frontend to know that is going on and it will maybe make things _a
> little_ easier for the backend.

Yes this is what I mean. Sure we can do it in system command, but we
can do configure there also, but we are not and I think it would be a 
good idea to decide on new tags whenever something is used alot, with 
the rest being left for system command kludges. 

> Why <builddir>? What's wrong with "builddir" as a <package> attribute?

same reason as the <patch> one, no other.  Why not as an "named" attribute,
as  I don't know if it is used enough, like only really two packages use the
technique, and it seems to be more like the 


type concepts we made than an attribute.

> We should constantly update "syntax.txt" (for example) when somebody
> suggest some change for the profile syntax, so we all know what's in use.

Yes agreed, I want to start submitting all this to cvs, but wanted to get a
basis of agreement here first.... Since it was changing alot. 

> BTW, Happy Holidays. :)

thx, they were fun, and yours?
Bryan Dumm 
who is Sore Loserman, I want him for president :)

More information about the alfs-discuss mailing list