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

Neven Has haski at sezampro.yu
Tue Dec 26 09:20:26 PST 2000


Hi,

I didn't reply to everything from this email, lots of stuff is in the code 
(in the comments) that I'm sending back in the second message.

> Profile needs updated to 2.4.3 (I say we hold there and 
> make no furthur upgrades to the profile until Gerard has
> 3.0 out and the new big infrastructure changes(ie. 2.4/glibc2.2)

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

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

> <mkdir dir="&LFS;/usr">bin etc include lib sbin share src var</mkdir>
> <link dir="&LFS;/usr" source="share/man" type="symbolic">man</link>  
> 
> Not only did we get rid of the cd element altogether, but we have
> also eliminated the idea of "being somewhere in the filestructure"
> and as a bonus, made each command above it's own seperate entity.

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

> That way we can have error or even message/output type routines, that
> process output to the user. I say this now, cause at some point most
> of the messaging coming from the backend will be xml based messages
> (think xml-rpc) that are then accepted by the frontend. If the frontend
> told the backend what type of client it was, we could even format messages
> appropriately? I know for now, since we will be using the console the 
> appropriate
> way to do it will be to dump text back in the error subroutine. But I 
> want to stir up some discussion on this method of doing things. 

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? 

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?

> I also think that we can use this final profile we mangle into reality
> as the basis for the upcoming LFS infosystem. If you think about it, 
> we already have built the "database" by building this profile. To build
> that database, it should not be much more in XML::Twig than adding a package
> handler to get all the package tags and then a simple package subroutine
> that say loads up all the xml information in a big hash and then dumps 
> the entire hash to database table(s).... We could also use this code for
> later package/profile additions to the infosystem.

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

> Also another helper script that I think we need is one that does the 
> following.
> 
> Untars a package
> Looks for an INSTALL file
> Reads it and looks for "This is a standard Install file"
> If found, then we run the ./configure --help and capture that output
> And based on that output, and the package info, 
> we make up an instant xml profile for that package
> 
> Not all packages are standard, and not all packages will work with
> our instant output. But I bet I could drain the archives say over 
> at freshmeat, run this script on those archives I collected and 
> probably have a fair amount of "working" ready to use profiles. Ideas
> on this are welcomed. 

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.

> We use:
> 
> <unpack archive="&packages_dir;/console-tools-0.2.3.tar.bz2">/usr/src</unpack>
> 
> but in <package> we declare a version and name. So can we use a construction 
> like the following:
> 
> <package name="console-tools" version="0.2.3" toplevel="&name;-&version;">
>          and
> 
> <unpack archive="&packages_dir;/&name;-&version;.tar.bz2">/usr/src</unpack>
> 
> 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.

> also, &packages_dir must change after we enter chroot because &LFS; won't be 
> valid anymore. We can do a quick dirty fix for that by running this command 
> immediately after we enter chroot:
> 
> cd /mnt
> ln -s / lfs
> 
> that way &LFS; will point to / so &LFS;/usr/src is just /usr/src
> 
> Or, we do it the proper way and redefine a few things.
> 
> 
> <Yea let's work out chroot element and the proper way, don't want kludges
> if we can avoid them>

I was thinking a lot about all this package location mess and didn't find a 
good solution yet.

First, we must have something like "&original_package_directory;" where _all_
the packages are located in the first place.
For the first part (before chroot) we can unpack packages from that directory.
For the second part, we would have to do some _copying_ (or just unpacking) from
that "&original_package_directory;" to the place inside "&LFS;" of all packages
before we enter chroot.
This should be of course controlled by a profile, so we can add a bunch of 
<copy> (or <unpack>) tags before <chroot> for the packages used in the post 
chroot part. 

But like I said, if somebody has a better idea ... I don't :)

> <system_command dir="&toplevel;/src" param1="-i 
> ../../gnutarpatch.txt">patch</system_command>
> 
> Tell me what you think of that (i know it's not a clean way but i'm not going 
> to 'invent' new tags right now).
> 
> < I think we need two new tags/elements(what should I call it) to deal with
> this, and those are <patch> and <builddir> or something like that. Those 
> are really the two issues that seem to keep popping up, causing us headaches
> and so on.>

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.

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

> textdump tag: was it <textdump file="filename"> or textdump target="filename" 
> ?  I assumed file="filename"
> 
> <I got file= but I think Neven used target=, and coming up with some 
> guidelines for attributes would end such questions, or minimize them...> 

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.

BTW, Happy Holidays. :)

Neven





More information about the alfs-discuss mailing list