[Rpm-metadata] xml update

[Jeff Licquia]

On Thu, 2003-10-16 at 13:52, Jeff Johnson wrote:
> 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?

Well, one would think that the information would be relevant to the
other packages on the CD.  Debian 2.0 Recommends and Suggests, for
example, still work when installing from Debian 2.0 CDs, even if they're
obsolete with regards to sarge or woody.  And when one decides to
upgrade, one gets a new set of up-to-date metadata, complete with new
E/S/R data to replace what's in the old packages.

Strictly speaking, Depends/Requires has the same problem.  What happens
with foo 2 removes behavior from foo 1, and some really old package
depends on "foo"?  Indeed, E/S/R are less susceptible to this problem
than Depends or Requires, since the package manager can decide to
override the suggestion when it makes sense.

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

If you're talking about implementing E/S/R outside of in-package
metadata, then I think you've already got it in comps.  Doesn't that
group packages together in recommended groupings?  How is that different
from Suggests or Enhances, other than the fact that you don't have a
distinction of degree as between Recommends and Suggests?

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

That sounds to me like an argument for making E/S/R a part of the
package metadata, since then it's clear that the distro vendor gets to
make those decisions.  

In Debian, the individual package maintainer makes the decision, with
very few constraints.  Despite the free-for-all this implies, Recommends
and Suggests have been useful for us.

Debian had a similar problem to yours, BTW.  There was a dispute as to
whether packages in main could Suggest or Recommend packages in
non-free; this pissed off FSF types.  OTOH, a proposal to ban that
practice in policy could never pass, since too many others wanted that
functionality.  Enhances was the result; a non-free package could
Enhance a free package, and therefore one could get away with
disallowing references to non-free in Recommends and Suggests, while
satisfying people who wanted non-free packages to get pulled in when
people wanted them.

So maybe what you want is Enhances; third parties can then Enhance
packages in the distro, and package tools can use that information.  At
the same time, the distro vendor isn't responsible for third parties; if
the third party freaks out and does something bogus, all he'll
accomplish is getting people to pull him from sources.list and its
equivalents.

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

Hmm.  Well, I'm way off-topic and far astray from my main area of
expertese.  But I hope my "advocacy" above is useful to you.  If not,
feel free to ignore it.

Regarding the metadata format, I don't mind whatever is decided, as long
as Debian packages are allowed to express E/S/R in some way.