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

Neven Has haski at sezampro.yu
Thu Dec 28 09:20:36 PST 2000


> 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......

Sure. There is also a Net::Jabber module from which we can get some nice ideas.

> > <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?

That was just a thought, I'm not sure I have a totally clear picture of all
this yet. I'll have to more thinking before I write something that will
make some sense. :)

> 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. 

Yes, I like this and we should definitely consider it.
It's probably a bit early though. Of course, we should have it in mind while
coding so we could easily implement it later.

> > 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. 

I'm still not quite sure if you meant (since you compared it with <configure>)
something like:

	<system_command dir="/package/to/patch" param1="-N" param2="-p1" 
	param3="-i" param4="/path/to/patch/findutils-4.1.patch">

or just:

<patch dir="/package/to/patch" param1="-N" param2="-p1">

Hmmm, now that I wrote it, I think I like the second option. :) 
It looks a bit clearer than <system_command>.

> > 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 
> <preinstall>
> <build>
> type concepts we made than an attribute.

Maybe we don't even need "builddir" at all? As we got rid of <cd> tag and since
<system_command> should have "dir" attribute it's not really needed. 
As for: "the backend/frontend to know the building directory", this can be
easily found out from the currently executed tag (ie from <system_command>).

Well, if you ask me, I would remove the "toplevel" attribute too. :)
It's not really needed either and if it is (will be), it can be obtain from 
inspecting the archive.

That way, <package> tag would only have "name" and "version" attributes which
I think it's nice. We could also add "desc" / "help" / whatever too, so that 
the tag would only contain the information that describes the package and
that's interesting for the user and nothing more. 

> > BTW, Happy Holidays. :)
> thx, they were fun, and yours?

Sure, thanks. The New Year is yet to come though ... :)


More information about the alfs-discuss mailing list