jamie_bennett at pcpmicro.co.uk
Fri Aug 6 01:38:39 PDT 2004
Kevin P. Fleming wrote on 06 August 2004 02:54
> Jamie Bennett wrote:
>> o complete split of front-end and back-end to allow
>> different front-ends and the compiling of profiles over
>> a network (think farming off profile compilation to one
>> dedicated profile compiling server).
> I'm not really sure what you mean by "profile compilation". My vision
> for nALFS2 was two pieces, nALFS and nALFSd, with nALFSd running only on
> the "target" system, where the build was actually going to occur. They
> could of course be run together on one system to do a build on that
> machine, and in fact the nALFS front-end should automatically start an
> instance of nALFSd (and talk to it over a socket pair) if it's not told
> to connect to an existing one.
I think we have the same idea here. I was thinking of running nALFSd on a
dedicated profile compiling server and have clients across the network run
nALFS2. The server (nALFSd) would compile the profiles selected by the
clients (nALFS2) to the clients network mounted drive. Maybe a bit ambitious
and I'm trying to convince the people who want it to not want it. Its not a
show stopper though.
>> o a new gui, web based for me, but could be anything (GTK/QT).
> The protocol to be used between nALFS and nALFSd is the big issue here.
Agreed, a standard protocol is definately needed here.
>> o SAX based parsing.
> Ahhh... parsing. I don't much care whether it's SAX or DOM, because I
> don't see any reason for profiles to continue to be monstrous combined
> entities. Rather, I'd like to see each package be in its own profile,
> and nALFS can be told to load a whole bunch of them and them sort them
> into a usable order (based on dependencies, stage names, etc). This will
> require nALFS to be able to feed entity values into the parser (which
> can be done with libxml2), and this is good because there has been a
> need to be able to provide environment variable values as entities
> within profiles for some time.
I've been using profiles with their own entities for some time now. Each
one is stand alone but all use one common %settings.ent file for build
destination and other common entities. I combine these for my needs but it
would be very nice to see nALFS2 do the sorting out of dependancies e.t.c
The ultimate idea would be to just see a profile with
and let nALFS2 sort out the in-between bits. SAX to me seems the best idea
for what we need. See next item.
>> o package downloading and verification before compilation.
> Yep, this is a biggie. We also need things like "actions to take on
> stage entry" and "actions to take on stage exit", to facilitate things
> like mounting/unmounting filesystems without having to manually mark
> those steps.
SAX allows for actions to take on entry/exit to a entity which would make
things alot easier for actions such as only checking dependacies, only
downloading and verifing, only extracting <description> tags e.t.c based
on state information.
>> o dependency resolution.
> Absolutely, and this will be a big task.
> I am thrilled to see some effort moving in this direction, and while I
> can't provide much coding time right now I'd be happy to provide any
> level of involvement you wish, from managing the project down to just
> being a resource for another viewpoint when you want it.
> Previously we discussed possibly using BitKeeper for this project
Ideally the LFS community would allow us to have a little corner for
nALFS2 and BitKeeper but if not I think the only option is to take it
to bkbits/another server as I feel BitKeeper would help a great deal on
a project like this.
More information about the alfs-discuss