[Rpm-metadata] repository isolation

[James Antill]

On Thu, 2011-01-20 at 15:34 -0500, Jon Wallace wrote:

> The intent is to understand limitations at a repository level and 
> whether we can think of the repository as part of a "bundle".

 You can _think_ of them that way, and a number of them work that
way ... but there is no std. way to enforce that. As I said, I know of a
few conversations that have been had about adding some functionality
like that to yum ... but the details are non-trivial, esp. as you try to
solve for all the different reasons people want "bundles".

 Eg.

blah <ver 2.1>
blah-updates <ver 2.1> (requires blah = $ver)
blah-updates-testing <ver 2.1> (requires blah-updates = $ver)

blah-clustering <ver 1.4> (requires blah >= 1.0)
blah-clustering-updates (requires blah-clustering = $ver)

blah-ha-db <ver 0.1> (requires blah >= 2.1 _and_ 
                      requires blah-clustering >= 1.4)

blah-source (relates to blah = $ver)

blah-debuginfo (requires blah/blah-updates = $ver)

...as you can see this quickly leads to needing a "mini. depsolver" to
work out which repos. you want/need (and after thinking about it for a
non-trivial amount of time, I'm still not sure what to do when
blah-ha-db ups it's requirement to blah 2.2 ... but you can't get blah
2.2 after a cache expire).

 Then there's the problem of where to put the data. The obvious
candidate is within the repomd.xml (Eg. as tags) ... but that means you
have to download the repomd.xml to even see the data, which causes
problems (as you can't just randomly refresh repos. ... and even
randomly turning them on/off can be confusing).
 The next obvious choice is the .repo files, but that means the data is
fixed basically "forever". Something in the middle using "yum vars"
might be doable, but while that is updateable it requires package
updates ... which is "not-good" at best.

 And that's just the yum POV.

 The general solution of: Have it all be implicit, and don't screw it up
too much ... still seems to be working, mostly.

> A different example would be trying to limit the size of repositories 
> that have similar packages.  So if PRODUCT_A and PRODUCT_B both need the 
> same rpm package (xyz.rpm) it would be nice if the physical rpm file 
> only had to live in one place and could be referenced from any other 
> number of repositories, similar to how symbolic links work.

 This is already possible:

mergerepo --repo=http://.../Fedora/releases/13/Everything/x86_64/os \
          --repo=http://.../Fedora/updates/13/x86_64/

...will produce a new repo. which just has repodata in it (all packages
served from the specified mirrors). Obviously you lose the full mirror
capability, which isn't nice ... and for your case you'd need to create
5 repos., 3 "internal" and 2 "external".
 Adding features to createrepo, or mergerepo is possible though.