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
_______________________________________________
Yum-devel mailing list
Yum-devel@lists.baseurl.org
http://lists.baseurl.org/mailman/listinfo/yum-devel
