[Rpm-metadata] new script, another update

Jeff Johnson n3npq at nc.rr.com
Sun Oct 19 17:00:48 UTC 2003


seth vidal wrote:

>>Hmmm, there hasn't been a new pkg format of significance in years. 
>>Whatever ...
>>    
>>
>
>no point in getting painted into a corner, though.
>
>  
>

No point in reconstructing a puzzle palace either, rpm crap is bad enough.

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

You're quite right that arch may need to be added somewhen.

However, if you look at the uses of rpm:entry, packages have arch while 
dependencies
have color. If you really want arch, I'm not averse to adding to 
dependency set objects
(which are the closest similar object to the rpm:entry XML 
representation), there may be reasons
to do so other than XML metadata.

No matter what, arch is the wrong namespace for packaging, and needs to 
die. Yes, every
known rpm user/application relies heavily on arch, known in excruciating 
detail.

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

Not surprised. Could you retrofit some tag value redaction please? No matter
what there's crap in rpm header tags, that should not be carried into 
rpm metadata.
Crap is crap.

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

Yes, I was just musing out loud about other uses for rpm metadata. Fell 
free to
ignore my idle fantasies, one of which is to steal the quite reasonable 
rpm-metadata
and push directly into v5 on-disk rpm packaging and the rpmdb using dbxml,
in order to kill off binary headers as a metadata format entirely.

What I need first is consensus on the XML representation, coming along 
nicely, thank you.

73 de Jeff





More information about the Rpm-metadata mailing list