[Rpm-metadata] xml update

Panu Matilainen pmatilai at welho.com
Thu Oct 16 18:09:15 UTC 2003


On Thu, 2003-10-16 at 20:40, Jeff Licquia wrote:
> On Thu, 2003-10-16 at 12:15, Panu Matilainen wrote:
> > On Thu, 2003-10-16 at 19:47, seth vidal wrote:
> > > anything that is specific to a particular packaging tool will need to be
> > > prefaced by a namespace for that tool and should not affect other tools
> > > 
> > > so
> > > <apt-rpm:priority>1</apt-rpm:priority>  seems reasonable  for
> > > repositories generated by apt-rpm's mechanism
> > 
> > I agree on "what is specific to particular packaging tool" part BUT
> > things like priority and Enhances are general concepts which *could* be
> > used by other tools as well. Lets say redcarpet adds support for
> > priority.. and then we have two different entries for the thing, one for
> > apt-rpm and one for redcarpet, both having the same data. Oh and one
> > more place to present that in Debian world...
> 
> I don't have a problem either way, but I will point out that there's no
> reason why, say, Red Carpet couldn't make use of the "deb" namespace
> when adding support for priority:
> 
> I'm also all in favor of finding generally useful metadata in practice,
> rather than guessing at it now.  If <deb:priority> turns out to be
> wildly popular in the RPM world, it can be promoted in a v2 of the
> metadata spec.

Oh sure, I'm not into adding every imaginable attribute as general data
either, just "obvious" ones. From practical point of view lets say we
already have two depsolvers using some data then it's quite likely the
data is relatively general -> should at least be considered for general
package data.

> 
> > Tool-specific hacks to tool specific namespaces but useful data should
> > be generally available, I'd feel quite silly adding code to apt-rpm to
> > poke through say, redcarpet namespace for some bit of information. If
> > the packaging tool doesn't understand / support some general tag then
> > simply ignore it...
> 
> I don't see any reason why it should be silly for apt to make use of Red
> Carpet metadata, or yum to use apt metadata, or up2date to use urpmi
> metadata, or anything else.

No reason why such things couldn't be done but if two or more depsolvers
find a piece of metadata useful it suggests the metadata is probably
general, not tool specific. I suppose much of these things will be found
through practise, not theory, once various parties start implementing v1
metadata support.

> 
> The only thing I would say is that package-tool-specific metadata should
> be optional; if the tool absolutely requires it, then it should be in
> the package-specific or general metadata.

Agreed.

	- Panu -




More information about the Rpm-metadata mailing list