Learn more about these different git repos.
Other Git URLs
From yum repolist -v fedora ...
Repo-id : fedora Repo-name : Fedora 13 - x86_64 Repo-revision: 1274245576 Repo-tags : binary-x86_64 Repo-distro-tags: [cpe:/o:fedoraproject:fedora:13]: rawhide
...this isn't rawhide though.
This gets created when we branch, and won't likely change even up to the final release tree. What would you suggest we use there instead of "rawhide"?
We should probably have written this down ages ago, this is off the top of my head ... but at least will stay around longer than IRC :).
The idea is that eventually we want to be able to work out a few things on the client side with the tags:
...my understanding was that we could probably do that with just two tags and so we were going to have:
dist tag: cpe:fedora:13=release
F-n updates binary x86_64:
dist tag: cpe:fedora:13:updates=release
F-n updates-testing binary x86_64:
dist tag: cpe:fedora:13:updates=testing
F-n updates source:
F-n+1 rawhide binary x86_64:
...the idea being that we could then ask rpmfusion to use something like dist tag: cpe:fedora:13:rpmfusion:free=release etc.
the content tag being just a single binary-$basearch isn't the end of the world, although all the arches in the repo. would be "nicer". The distro. tag is pretty useless atm. though :(.
Sounds to me like we need to have a conversation with the other producers and consumers of these tags. I think we've proven we can generate some of the tags, we just need some agreement on what they are going to be. Can you do that and report back when you have a more firm idea of what you want listed?
James/Seth - more info on what you want?
Who are these other consumers? AFAIK this just needs to be something that koji starts doing to an ad hoc "std." ... then we can goto rpmfusion/etc. and say "do this, and get features X, Y and Z".
If you want to have a phone call, arrange one.
I note that F-14 fedora repomd currently has:
<distro cpeid="cpe:/o:fedoraproject:fedora:14">rawhide</distro>
...where something like "prerelease" or would be nicer, and then "release" when it's goes GA.
Right now, these values are driven by mash config files. While it's relatively easy to change the branched config file to say something like "prerelease", it gets trickier to change that to say "release" when that time comes. This is because to compose out the release repos, we just copy the branched compose over to the Everything/ tree (and scrub the installer bits along the way). So we would have to make the mash config change before we start making release candidates, and then we'd have a repo in development/ saying that it's "release". Either that or we have to re-run createrepo on the Everything tree to change out this value. Do-able, but human error prone.
Also, if you want the multilib dirs to list binary-<arch> and binary-<multiarch> that would require more changes in mash.
Probably the "safest" route here is to have a release ticket item to edit the mash file when we reach our final change deadline and start trying to make a release candidate so that the tags go from "prerelease" to "release". Thoughts?
It does not appear that there is something that needs to be done anymore. If there is, please re-open this ticket.
Log in to comment on this ticket.