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 :).
¹ See http://cpe.mitre.org/ and /etc/system-release-cpe
--
James Antill <[EMAIL PROTECTED]>
Fedora
_______________________________________________
Yum-devel mailing list
Yum-devel@lists.baseurl.org
http://lists.baseurl.org/mailman/listinfo/yum-devel
