[Rpm-metadata] xml update

[Jeff Licquia]

On Thu, 2003-10-16 at 12:49, Jeff Johnson wrote:
> Panu Matilainen wrote:
> 
> >On Thu, 2003-10-16 at 19:56, Jeff Johnson wrote:
> >
> >Which reminds me.. the current xml suggestion doesn't have anything for
> >per-repository/channel data. I suppose that's just "haven't had time
> >yet" from Seths part but that deserves attention as well. Things like
> >repository name, distro/version compatibility info... Apt's
> >release-files have all sorts of information which needs to be mapped
> >somewhere and this is imho a good chance to make the release* entries
> >more understandable to non-debian folks :)
> >  
> >
> 
> The issue (imho) is one of precednce in a contains relation.
> 
> Assuming an XML syntax to represent the entities below, the interesting 
> and important
> question is
>      Should repositories contain packages, or should packages have 
> repository attributes?
> 
> There's a similar problem with another collection aggregate called 
> "comps" that
> is used meaningfully by all of anaconda, yum, and redhat-config-packages.
> 
> I can (and have ;-) argued for "packages having repository attributes" 
> because
> that is most useful for my rpm purposes, where a package is the clear 
> and obvious
> choice as the primary data object to be managed.
> 
> OTOH, there also very useful unifications with the alternative 
> "repositories contain
> packages" put forward, for comps, by skvidal.

The two aren't necessarily mutually exclusive.

Apt, as designed, is very much a "repositories contain packages"
system.  But Debian's approximately equivalent system to comps, tasksel,
is very much a "package having repository attributes" system.

Personally, I think the former is more appropriate for physical
repositories, while the latter is more appropriate for logical groupings
of related packages, like tasksel and comps.

> There are certainly no interesting distinctions between the two 
> approaches, each
> achieves the goal of aggregation of packages into 
> collections/repostories/comps/whatever.

Not quite.  Take, for example the problem of whole-repo signatures.  If
a package can add itself to a repo with the simple addition of metadata,
it can cause a synchronization problem between the signed repo manifest
and the package metadata.

The very fact that signed repos require a signed manifest implies that
the package metadata is redundant for that purpose.

> However (imho) there may be useful performance gains in data retrieval by
> preferring one or the other means to achieve aggregation.
> 
> Also, one of the original goals of rpm-metadata was a compact, easily 
> downloaded,
> encapsulation of metadata. Adding Yet More Stuff is somewhat at odds 
> with that goal,
> even if useful for folks who have to scratch their eyeballs maintaining 
> XML ;-)

Namespaces mean that no XML file is so bloated that we can't add more.
:-)