remove alfs-discuss Digest

Claes Bengtsson claes.bengtsson at tietoenator.com
Wed Apr 3 04:07:34 PST 2002


On Wednesday 03 April 2002 13:00, you wrote:
> alfs-discuss Digest	Tue, 02 Apr 2002	Volume: 03  Issue: 063
>
> In This Issue:
> 		new perl alfs
> 		RE: Unwanted Optimizations
>
> ----------------------------------------------------------------------
>
> Date: Tue, 2 Apr 2002 14:05:21 +0100
> From: Mark Ellis <mark.uzumati at virgin.net>
> Subject: new perl alfs
>
> Normal place http://freespace.virgin.net/mark.uzumati
>
> Nothing particularly exciting, XInclude works and some new optins for
> <copy>.
>
> The one major difference is the removal of support for the old syntax
> style, the old processing has been removed and as a stopgap profiles
> will not be processed unless the <alfs> version begins with a '2',
> though we really need to work out some consistent versioning :)
>
> I have no idea how many people still use the old syntax, but it was
> becoming a pain, and will be more so if we implement <stage> or any of
> the alternatives that have been discussed. There is an XSLT stylesheet
> on the web site to convert from old to new style, i haven't had a
> chance to sort out if it is possible to keep entities through the
> transformation, i suggest in the meantime keep your old profiles as
> they are, and use the stylesheet to produce an intermediate until this
> is fixed, if possible.
>
> Any problems let me know, i've done some testing of the conversion, but
> the old style syntax had some, um, freedom of expression which made it
> a bit fiddly.
>
> No i dont plan on adding XSLT support to perl alfs any time soon :)
>
> Mark
>
> ------------------------------
>
> From: "Silviu Julean" <juleans at arad.ro>
> Subject: RE: Unwanted Optimizations
> Date: Tue, 2 Apr 2002 19:26:21 +0300
>
> > You could use a <stage> element do simply replace a <prebuild> element
> > if you wanted to. But it could do more as well.
>
> Are you going to REPLACE the current DTD with <stage>-like tagging or going
> to use it in addition, to specify more stage information *if wanted*?
>
> > <stage>
> >    <stageinfo>
> >       <name>Prebuild</name>
> >       <user>lfs</user>
> >       <chroot>&LFS;</chroot>
> >       <base>/usr/local/src</base>
> >    </stageinfo>
> >    ... Do some stuff
> >
> >    <stage>
> >       <stageinfo>
> >          <name>Prebuild - cleanup</name>
> >       </stageinfo>
> >       ...
> >    </stage>
> >    ...
> > </stage>
>
> If it's that versus
>
> <chroot dir="&LFS;">
> 	<prebuild>
> 	... Do some stuff
> 	</prebuild>
> </chroot>
>
> i'd choose the last one... Why get complicated when the current synthax is
> doing the job? And to specify more information,
>
> <prebuild info="Fooing" comment="This performs a foo-ing (using foo-3.2.5
> in /usr/bin/foo) before the actual compilation">
>
> just like the alt="" parameter used in HTML <img> would do.
>
> IMHO your DTD specifies way too many stand-alone tags, when more parameters
> could be used. I find the HTML DTD an excellent example, and, as i am using
> HTML for nearly 4 years now, i guess i never used a visual editor because
> it's so easy to write. And though the new, fancy additions like <embed>s
> and <object>s have a somehow nasty synthax, the simplicity making a
> visually attractive document can't get any better. The same could apply to
> your synthax, if some condesation would be done.
>
> Neven: i'm not here to complain, i know it's been a damn hard (team)work;
> all i'm saying is that, thinking of all end-[l]users, this great automation
> system could be used by non-LFS users too.
>
> PS: if you're not replacing any tags in the current DTD, just ignore this
> (tho my remark goes a bit deeper than that)
>
>
> ------------------------------
>
> Subject: XML use (was: Re: Brainstorm: <stage>)
> Date: Tue, 02 Apr 2002 23:44:55 +0200 (MEST)
> From: =?ISO-8859-1?Q?Lo=EFc_P=E9ron?= <loic.peron at bigfoot.com>
>
> Quoting alfs-discuss at linuxfromscratch.org:
> > alfs-discuss Digest	Mon, 01 Apr 2002	Volume: 03  Issue: 062
>
> Hi,
>
> I just read all of the discussions that took place last week,
>
> and I have some remarks:
> > Date: Mon, 1 Apr 2002 22:57:19 +0100
> > From: Mark Ellis <mark.uzumati at virgin.net>
> > Subject: Re: Brainstorm: <stage>
> >
> > On 2002.04.01 10:11 Neven Has wrote:
> > > I like the idea of creating a new environment (so there is no need
> > > that
> > > the user previously unsets all not needed variables). Which together
> > > would give us something like:
> > >
> > >     <environment mode="set|add">
> > >         <variable mode="append" name="" value="" />
> > >     </environment>
> > >
> > > Although, I think that:
> > >
> > >     <environment mode="add">
> > >         <variable>
> > > 		<name>HOME</name>
> > > 		<value>/root</value>
> > > 	</variable>
> > >
> > >         <variable mode="append">
> > > 		<name>PATH</name>
> > > 		<value>/static/bin:/static/usr/bin</value>
> > > 	</variable>
> > >     </environment>
> > >
> > > would be more clearer/structured/more XML-like/whatever... ?
> > >
> > > In the past we were so desperately trying to run away from the
> > > amount of attributes there were in the syntax
>
> May I ask why? (seems I was not around at that time)
>
> > I like the element structure rather than the attributes too, though in
> > this case we could probably go with either, its a "look and feel"
> > thing.
>
> I don't think it's just a "look and feel" thing:
> AFAIK, elements, attributes and content have different particularities:
> (not including rules forced by a DTD)
> . elements are first-class items, whitch are layed out in a tree with
>   parent-children relations, with ordered children of any number and
>   type (content or element)
> . attributes are second-class items, whitch are directly dependent on
>   the element they are in, are not ordered and cannot be more than one
>   of a type
> . content is a third-class item, contained in elements, but having no
>   other XML signification than "a big chunk of text"
>
> Thus, there are some rules that can easily and efficiently drive a choice
> between a child-element and an attribute:
> . how many of this item will be found under this element:
>   _ if more than one, then make it a child-element
>   _ else better an attribute
> . is there an ordering information compared to other items:
>   _ if yes, then make them child-elements
>   _ else better an attribute
> . is the item's content complex (more than a bare string):
>   _ if yes, of course make it an element
>   _ else better an element
> . is the item's content a chunk of text:
>   _ if yes, make it the elements's content
>   _ else better an element
>
> Now, more on with some of the rules that can be forced by a DTD:
> . elements order (groups, sequenses) and number (0, 1, N, 0..1, 0..N, 1..N)
> . attributes presence, default value, allowed values
>
> Following those principles, most of what is actually contained in
> elements should be in attributes:
> . all path and path-like values
> . all boolean values
> . all command-line parameters
> . all short strings (package name, version, ...)
>
> I re-suggest you to have a look at ANT, and particuliarly at it's syntax:
> http://jakarta.apache.org/ant/manual/index.html sections entitled "Using
> ANT" and "Built-in tasks".
>
> I will try to write an example of how I would like to use the
> tasks/commands that have been listed at this time, but I can't guarantee
> anything.
-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe alfs-discuss' in the subject header of the message



More information about the alfs-discuss mailing list