[Rpm-metadata] new script, another update

seth vidal skvidal at phy.duke.edu
Sun Oct 19 16:17:02 UTC 2003

> Hmmm, there hasn't been a new pkg format of significance in years. 
> Whatever ...

no point in getting painted into a corner, though.

> I again again again suggest associating N with EVRF. I can think of no 
> context
> where all of NEVRF are not associated as unit. But perhaps I have missed 
> something ...

the only problem I have with this is that it seems un-pretty to leave
arch out of the list but you can't list archs inside deps/prov/etc.
so you end up with
<nevrf> </nevrf>
<arch> </arch>

maybe it's not big deal - it just seems awkward. And I'm not sure what
advantage you buy out of having them all in one tag.

> I also seem to see trailing blank in
>    <rpm:group>System Environment/Base </rpm:group>
> I do not know whether that is your script or rpm's tag value. No matter
> what, the trailing space should be dealt with.

it's something in the data in the header. I think it might be a trailing
\n - I think I'll check and clear that/those characters off the end,
eventhough it won't effect the xml at all.

> You might also consider mapping rpm "foo(bar)" dependencies into
> different XML name space, but that might be premature. IMHO, there
> is little need to carry rpmlib(...) or config(...) dependencies around, and
> a real need for "perl(...)" CPAN dependencies to be cleanly split out for
> seperate vetting, but that's above and beyond the original depsolver scope
> of rpm-metadata XML format.

The only problem I have with this is that it puts A LOT of intelligence
into the format and the parser/creator of the format. That seems like a
bad call b/c you end up with too many places for errors inside the
format tools. It seems more appropriate to accurately describe the data
in the header rather than attempt to interpret that data.


More information about the Rpm-metadata mailing list