Alfs Update - have time before reading.........
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 @ jabber.org 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>)
<system_command dir="/package/to/patch" param1="-N" param2="-p1"
<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
> 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