[Rpm-metadata] xml update

[Jeff Johnson]

seth vidal wrote:

>>>If they ARE used b/t multiple depsolvers the sure. But I don't think
>>>anyone wants the union of all things that _COULD_ be used by more than
>>>one depsolver - and that's what you're talking about here. Not a
>>>graceful intersection with namespaces for desired other areas.
>>>      
>>>
>>"Can", for "obvious" cases. The fact that none of the current depsolvers
>>support something that another depsolver supports has something to do
>>with the fact that there's no common metadata?
>>
>>    
>>
>
>does it?  if it were as common as is being suggested then others would
>have implemented it in their metadata. right?
>
>  
>

There is hysterical legacy associated with rpm packaging that has prevented
Enhances: and Suggests: from developing naturally.

The major impediment, which I, and ewt before me, is/was adamant about, 
is that
Enhances:/Suggests:/Recommends: will *never* be in rpm packages, as the 
information
rots too fast to be useful. Consider a package built 3 years ago, burned 
on CD. Of what
use are any packaging hints contained in that package? If the data is 
flawed, why bother
inventing semantics for an implementation?

Common metadata, since it is not (yet, at least) burned on dusty CD's, 
solves the one
crucial impediment to developing semantics for E/S/R in rpm depsolvers, 
not in a package.

 From private discussions with ewt years ago, rpm is definitely missing 
one of E/S/R, but
neither one of us could figger what semantics should be implemented in 
rpm, and so
development has never happened.

I suggest that it's time to figure out how to use E/S/R hints in rpm 
depsolvers, the problem
is very well known.

The other looming issue with E/S/R wrto rpm is
    Who gets to decide the when/where/why of adding any of E/S/R?
If bogus data is deployed in the field, lots and lots of users become 
irate. When anaconda
was the only installer around, the risk associated with adding E/S/R 
that would be abused
and misused by various package monkeys was overwhelming.

Now, with yum/anaconda/apt-rpm/r-c-p/up2date/redcarpet/rpmfind/whatever 
there is significantly
more experience on how to develop semantics and implementations for 
additional depsolver
hints.

>  
>
>>For a example I see Enhances & Suggests as something which would be
>>useful for many depsolvers. Installing xmms? You know, this only gives
>>you ogg support, you probably want to play mp3's as well, should I
>>install xmms-mp3 for you as well?
>>    
>>
>
>but where do we get that data from?
>

 From common metadata of course. Not yet, of course, too; thought about 
implementations
needs to be done first.

>When building the file - where does this data come from - in debs the
>data is in the package header afaict - so where do the rpm people
>extract it from? Where does apt-rpm store it - b/c then _that_ metadata
>file is critical.
>  
>

Let me ask the question slightly differently:
    How is common metadata content going to be maintained?

If automatically generated from queries, I can/will add a header 
extension for E/S/R
to map the values into a different, independently maintained file. This, 
btw, is the
point of meta-meta data, associating additional info with, but not in, a 
package.

73 de Jeff