[Yum-devel] Tags, release and re-solving a few old problems

[seth vidal]

On Thu, 2008-10-23 at 14:01 -0400, James Antill wrote:
> The latest 3.2.19 in rawhide/Fedora 10 parses out the tags data
> recently discussed on the rpm-metadata list, and createrepo can add it
> in. So I'm planning on re-solving a couple of problems, and adding a
> plugin to do some new stuff. Please feel free to
> discuss/reply/object/etc. :).
> 
>  ---- recap ----
> 
>  We added three things to the repomd.xml for each repo.:
> 
> 1. content tags: set of string tags on the packages in the repo.
> 
> 2. distro tags: set of string tags on a distro. (uses cpe¹)
> 
> 3. release string: a single string which is the "release" for the repo.
> (defaults to time_t for the createrepo run).
> 
> ...an example of which is (just paste this into the top of a repomd.xml
> file and run repoMDObject.py on it):
> 
> <release>Foo bar 9.1.666</release>
> <tags>
>   <content>foo</content>
>   <content>bar</content>
>   <distro cpeid="cpe://o:fedora_project:fedora:9">foo</content>
>   <distro cpeid="cpe://o:fedora_project:fedora:9">bar</content>
> </tags>
> 
> ...and we also have:
> 
> 4. "timestamp" of the repomd.xml, as used by MM/metalink etc. (yum
> repolist -v shows this) it's the old timestamp on any of the metadata in
> the repomd.xml.
> 
> 
>  ---- out with the old ----
> 
> p1. Current yumdownloder --source, and debuginfo-install enable repos.
> by doing """Find any repos ending in "-source" than start with something
> that is enabled.""". We also do a similar ad hoc thing in sqlitesack, so
> that we can turn source repos. off without doing much work.
> 
>  This has always been kind of hacky, and only allows one
> source/debuginfo repo. for each "parent" repo. ... it is also more
> important to fix sooner because PackageKit refuses to implement the
> above logic, due to non-portability to make etc.
> 
> 
> s1. The obvious way to fix this, is to have two pieces of information:
> 
>         i. is this a source/debuginfo/etc. repo.
>         
>         ii. this repo. should be enabled when repo. X is enabled (and
>         you want to autoenable source/debuginfo/etc.)
>         
> #i seems like an obvious candidate for a content tag, and a
> yb.repos.findWithTag('source') API.
> 
> #ii is less obvious, we can use the "release string". ie. foo-source and
> foo-debuginfo repos. would manually be given the same release string as
> the "foo" repo. (which could just be "Fedora 9 x86_64").
>  We could introduce another tag, say a "parent" tag which points to the
> release or repoid explicitly.
> 
>  The other option would be to use distro tags in #i and say something
> like: if the repo. has a distro tag of source, and a matching distro tag
> of "main" is enabled ... autoenable this repo
>  API being something like: 
>  for (repo, distro) in yb.repos.findWithDistroTag('source'):
>    if yb.repos.findWithDistroTag('main', distro=distro, enabled=True):
> ...of course that might do weird things due to cpe matching.
> 
> p2. Kinda related, atm. in Fedora we have updates-testing and
> rawhide ... it'd be nice to be able to say "enable testing" or "enable
> development".
> 
> s2. Just adding content/distro tags and looking enabling based on that
> seems sane and easy.
> 
> 
>  --- in with the new ----
> 
>  For the new stuff, I think most use cases will be similar to the above
> in that people will want to turn repos. on/off based on some combination
> of the tags ... and I know we want at least something like "only use
> repos. with release = FOO".
>  Anyway think of any other use cases? (anyone thinking about
> yum-tag-priorities gets a free stabbing from Seth :).
> 

I think we'll need to preserve compat with older repos for quite a
while.

I'd hold off on putting the above changes into effect until the F11
devcycle is underway.

-sv