David Hollis wrote:
On 06/21/2011 07:39 AM, Karanbir Singh wrote:
One option we have is to make the CR repo available on only a few machines, isolate those from regular mirror.c.o taffic and push a centos-release-CR rpm that people need to manually install on their machines to 'opt in'. We could then obsolte: that centos-release-CR rpm with the centos-release that comes down the road when the isos/ are in place and the new release announced. This seems to be the cleanest way to do things. It also means we can clean out the CR rpms once the point release is published and not need to maintain it forever as a giant well of rpms.
I think that this makes sense. With the added benefit that since the -CR repo rpm would be removed so the user wouldn't get an ugly surprise on during the next point release cycle if they weren't wanting the updates at that time.
Would there be any mechanism for ensuring that if you participate in the CR repo that if you installed a 'preview' rpm but it had some issues and was rebuilt that you would get the rebuilt rpm? Or would that just be the chance you take and you would have to hope that the package gets an update and release # increment to get updated to 'stable'?
If nothing else, yum in 6.x has history of what was updated, and if I remember correctly you can reinstall those same packages. If this is true, you can manually or automatically order yum to reinstall those packages just in case. Maybe mandatory reinstall of all packages installed that indicate they are installed from "@cr-repo" should be in order.
I am not sure about 5.x. If something similar exists for 5.x (and 4.x?), in for of a yum plugin, centos-release-CR could depend on install of that plugin and use it to remember all packages installed from that repository, so reinstall can be forced on those packages, just in case.
Ljubomir