On Saturday, February 2, 2002, at 05:11 , Max Horn wrote:

At 16:50 Uhr -0500 02.02.2002, Kyle Moffett wrote:
I would like to propose a format for XML info documents for Fink.

[snip]

Actually, in my mind, there is no difference at all - even the "final" format would be parsed into the same hash format as we have now. The main difference is that multiple variants would generated multiple package entries.

For the 'final' format:

What I was thinking was that variants could be much better handled if we created a two (or maybe three) level hash, because then we could do something like

$hash->{cppflags} = the package's default value for CPPFlags
$hash->{variants} = an array of different variant names pulled from the package file
$hash->{variant}{xwin} = the contents of the variant foo
$hash->{variant}{xwin}{cppflags} = the CPPFlags used when compiling with xwindows support

Then stuff could be specified:

[...]
<variant name="xwin" displayname="XWindows support">
<set method="add" env="CPPFlags" value="-I/usr/X11R6/lib"/>
<configure method="replace" parems="--with-xwindows"/>
</variant>

Then normal variables would be read first, and variants would be read in a loop afterwards, either keeping the default's variables, keeping them with additional values, parameters, etc, or replacing them with their own.

Similar things could be done with the shlib support


[snip]

<require [type="depends, builddepends, provides, conflicts, replaces or predepends"] package="bar"/>
<suggest [type="suggests, recommends, or enhances"] package="bar"/>

I don't like this to much. <require type="provides"> feels awkward to me. So I personally would go for having different elements for each. Maybe like this:

<depends package="foo">
<depends type="build" package="quux"/>
<conflicts package="bar" version="<<1.0"/>

Agreed, though in the future, it might also be legal to do:

<require at="all" installed="foo"/>
<require at="build" uninstalled="bar"/>

<custommirror>
<nam-US url="http://other.source.site/mirror/"/>
<asi-JP url="http://last.source.site.jp/mirror/"/>
</custommirror>

Using the locations as element name is not good, since it prevents us from writing a proper DTD. I'd rather see something like this:

<custommirror>
<mirror continent="nam" country="US" url="http://other.source.site/mirror/"/>
<mirror continent="asi" country="JP" url="http://last.source.site.jp/mirror/"/>
</custommirror>

A dtd is technically optional, from the point of view of the parser, but we could easily extend our validation if one was included. Also, for some cases, the list of mirrors is huge, and that would take extra space and bandwidth. A better suggestion is:

<mirror place="nam-US" url="http://other.source.site/mirror/"/>
<mirror place="asi-JP" url="http://last.source.site.jp/mirror/"/>


<update>
<configguess [ default="true or false" ] [ dirs="mydir myotherdir"] />
<libtool [ default="true or false" ] [ dirs="mydir myotherdir"] />
<pomakefile/>
<pod/>
</update>

We don't need the "default" attribute you suggest, I think. I know you can currently say "UpdateConfigGuess: false", but that is completly superfloous to do, i.e. you could just as well leave out the line.

When I was writing that, I was reading the stuff on the fink site, the field descriptions and such, and since this is a transitional format, we need to be compatible with the old hash. Since the field UpdateLibtool: true updated the directory . but the UpdateLibtoolInDirs field didn't unless specified, I thought that we'd better include that as default="true". However, we could just have the maintainer include . in the directory list if they want that directory. So,

<update>
<configguess dirs=". mydir myotherdir"/>
<libtool dirs=". mydir myotherdir"/>
<pomakefile/>
<pod/>
</update>


Nice idea, also I worry how feasible it is to include scripts directly - charachters like <, ", > and & occure quite frequently inside scripts. That is really an issue with XML, which we have to consider.

Actually, the above script could be written without the <![CDATA[ ]]> stuff, since it has no special characters. Also, " is not a special character except inside the tag.

[snip]

That's not XMLish :) The files should be split up, like this:
<docfiles>
<file name="README"/>
<file name="LICENSE"/>
<file name="NEWS"/>
</docfiles>

Agreed, but it's easier to type them all strung together like that :)
Or, <docfile name="README"/>

[...]

Kyle Moffett

Cheers,

Max
-- -----------------------------------------------
Max Horn
Software Developer

email: <mailto:[EMAIL PROTECTED]>
phone: (+49) 6151-494890

Reply via email to