On Tuesday 01 of November 2005 23:16 Ciaran McCreesh wrote:
> | How will it handle GLSAs then? [1]
>
> gentoolkit != portage.

To quote GLEP 14 [1]:

"Once this tool is implemented and well tested it can be integrated into 
portage."

> | > It's not a question of "what's wrong with XML?". It's a question of
> | > "what advantage would we gain by strapping a giant flapping wet
> | > kipper to a bicycle?".
> |
> | Or (a little bit rephrased) "why should we stick with consistent file
> | formats".
>
> Uh, you'd have to invent a load of new XML DTD stuff for this anyway.

Nope. We can build on *existing* GLSA DTD and on *existing* code. The downside 
is that Portage integration could be slower (same case as with `glsa-check`, 
AFAIK).

> So you're not using a consistent file format at all, you're just using
> a consistent unnecessary layer in the middle, which as a side effect
> makes your files incompatible with every standard Unix tool ever
> written.

See below.

> Using XML does not magically make things compatible. XML is just a
> layer in the middle. Any tool processing XML files still has to worry
> about however the DTD in question works.

Just to clarify - I don't say that XML is The Best Way To Go (tm), I'm just 
pointing out another possibility of implementation which is *very* similar to 
the way GLSAs are processed. 

GLSA already contains stuff for marking items as valid only for given systems, 
for "injecting" them etc. Why don't use existing code? Why duplication?

Have a look at the XML source of any GLSA.

> You think XML magically makes things compatible? Then I suggest you
> write a GuieXML to Docbook conversion tool, and see how many thousand
> lines of XSLT it takes. All XML does is move the conversion and parsing
> problems to a different, more complex level.

I'm not familiar with DocBook, but I doubt I'll need thousands of lines of 
code.

[1] http://www.gentoo.org/proj/en/glep/glep-0014.html

WKR,
-jkt

-- 
cd /local/pub && more beer > /dev/mouth