On 06/21/2011 01:11 PM, David Hollis wrote:
> 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.

Right, and we dont need to maintain that CR repo for the life of the
point release it was setup for. Since everyone would have the default
$releaever/updates/$basearch repo enabled anyway. Since CR would not
replace updates/ it would be an additional repo.

> 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 there is a need to rebuild a package that is already in the CR repo,
in order to maintain sanity we would need to bump release. The
distrosync plugin for yum would help - but its hard to make sure that
everyone using CR would have it and have it enabled.

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Manuel Wolfshant wrote:
>> 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.
> I am not sure I get this part. Since the packages are not changed ( I
> presume the NEVR remains the same when the packages are moved from CR to
> "stable"), how would this "obsolete" process happen ? I am used to the
> fedora / fedora epel "testing" phase which is basically
> - packages are first pushed to a testing repo which is not enabled by
> default on client computers
> - after a) enough people test and validate a package or b) enough time
> has passed since the package was pushed to the testing-repo the package
> can be moved to the stable repo

Trick is that CentOS will not change NEVR or version number if they
recompile package with diferent build environment. It could look exactly
the same, size and all, but it would act differently.

In Fedora/EPEL way, when you change anything you also change version
number, but it is not so in RHEL rebuilds. version and NEVR *must* stay
the same, even if correction is made. Hence the original problem in
question, how to pass the info about rebuilded packages to yum.

Ljubomir
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 06/21/2011 04:24 PM, Ljubomir Ljubojevic wrote:
> Manuel Wolfshant wrote:
>>> 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.
>> I am not sure I get this part. Since the packages are not changed ( I
>> presume the NEVR remains the same when the packages are moved from CR to
>> "stable"), how would this "obsolete" process happen ? I am used to the
>> fedora / fedora epel "testing" phase which is basically
>> - packages are first pushed to a testing repo which is not enabled by
>> default on client computers
>> - after a) enough people test and validate a package or b) enough time
>> has passed since the package was pushed to the testing-repo the package
>> can be moved to the stable repo
> Trick is that CentOS will not change NEVR or version number if they
> recompile package with diferent build environment. It could look exactly
> the same, size and all, but it would act differently.
>
> In Fedora/EPEL way, when you change anything you also change version
> number, but it is not so in RHEL rebuilds. version and NEVR *must* stay
> the same, even if correction is made. Hence the original problem in
> question, how to pass the info about rebuilded packages to yum.

you are 100% correct. hence my "how would this "obsolete" process
happen?" question
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 06/21/2011 02:02 PM, Manuel Wolfshant wrote:
>> 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.
> I am not sure I get this part. Since the packages are not changed ( I
> presume the NEVR remains the same when the packages are moved from CR to
> "stable"), how would this "obsolete" process happen ? I am used to the
> fedora / fedora epel "testing" phase which is basically

so lets take an example:
5.6/os/centos-release-5-6.0.i386.rpm
5.6/os/ < has no centos-release rpm >
5.6/CR/updates/centos-release-CR-5-7.0.i386.rpm ( which only contains
the repo definition for the CR repo )

and when there is a 5.7 :
5.7/os/centos-release-5-7.0.i386.rpm ( with an Obsoletes:
centos-release-CR <= 5-7.0; and drop a copy of this rpm into the 5.6/CR/
repo as well.

Would that work ?

> - packages are first pushed to a testing repo which is not enabled by
> default on client computers
> - after a) enough people test and validate a package or b) enough time
> has passed since the package was pushed to the testing-repo the package
> can be moved to the stable repo

we could/should do that anyway with the QA repo's - but as we saw in the
past, that sort of testing can be done by a dedicated group of people
fairly quickly when they are doing the testing for the sake of testing
by design.

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On Tuesday, June 21, 2011 09:24:11 AM Ljubomir Ljubojevic wrote:
> In Fedora/EPEL way, when you change anything you also change version
> number, but it is not so in RHEL rebuilds. version and NEVR *must* stay
> the same, even if correction is made. Hence the original problem in
> question, how to pass the info about rebuilded packages to yum.

Checksum. This is used by the yum 3.4.x option 'distro-sync full' to do just exactly that; it does the distro-sync, and also will reinstall packages that have the same NEVR but different checksums.

You can try it out on Fedora, but you'll need yum 3.4 or later installed to do it. Yum 3.2.28 (F14) and yum 3.2.29 (current EL6, as referenced from a RHEL 6.1 install) have distro-sync, but not the 'full' option. The 'full' patch might apply cleanly to 3.2.29, but I have not had a chance to try it.

This discussion was up-thread already.....back on June 3rd.
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 06/21/2011 02:33 PM, Lamar Owen wrote:

> You can try it out on Fedora, but you'll need yum 3.4 or later installed to do it. Yum 3.2.28 (F14) and yum 3.2.29 (current EL6, as referenced from a RHEL 6.1 install) have distro-sync, but not the 'full' option. The 'full' patch might apply cleanly to 3.2.29, but I have not had a chance to try it.

there is a yum-3.4 in the pipeline for c5-testing, should be there
tomorrow at some point.

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 06/21/2011 04:37 PM, Karanbir Singh wrote:
> On 06/21/2011 02:33 PM, Lamar Owen wrote:
>
>> You can try it out on Fedora, but you'll need yum 3.4 or later installed to do it. Yum 3.2.28 (F14) and yum 3.2.29 (current EL6, as referenced from a RHEL 6.1 install) have distro-sync, but not the 'full' option. The 'full' patch might apply cleanly to 3.2.29, but I have not had a chance to try it.
> there is a yum-3.4 in the pipeline for c5-testing, should be there
> tomorrow at some point.
and it will be happily ignored by anyone wishing to stay close to
upstream. but I assume those will happily ignore -CR , too
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 06/21/2011 04:29 PM, Karanbir Singh wrote:
> On 06/21/2011 02:02 PM, Manuel Wolfshant wrote:
>>> 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.
>> I am not sure I get this part. Since the packages are not changed ( I
>> presume the NEVR remains the same when the packages are moved from CR to
>> "stable"), how would this "obsolete" process happen ? I am used to the
>> fedora / fedora epel "testing" phase which is basically
> so lets take an example:
> 5.6/os/centos-release-5-6.0.i386.rpm
> 5.6/os/< has no centos-release rpm>
> 5.6/CR/updates/centos-release-CR-5-7.0.i386.rpm ( which only contains
> the repo definition for the CR repo )
>
> and when there is a 5.7 :
> 5.7/os/centos-release-5-7.0.i386.rpm ( with an Obsoletes:
> centos-release-CR<= 5-7.0; and drop a copy of this rpm into the 5.6/CR/
> repo as well.
>
> Would that work ?
>
I meant the packages themselves, not the centos-release.rpm. this one is
trivial
my concern is the mechanism which would trigger reinstallation of
packages which are modified between their existence in CR and the
stable/updates phase


_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

On 06/21/2011 02:48 PM, Manuel Wolfshant wrote:
> I meant the packages themselves, not the centos-release.rpm. this one is
> trivial
> my concern is the mechanism which would trigger reinstallation of
> packages which are modified between their existence in CR and the
> stable/updates phase

we need to make sure that we dont get into that situation. So only ship
to CR once we are happy with the package itself.

it does mean that some packages like anaconda and friends will never
make it to CR.

- KB
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel

Karanbir Singh wrote:
> On 06/21/2011 02:02 PM, Manuel Wolfshant wrote:
>>> 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.
>> I am not sure I get this part. Since the packages are not changed ( I
>> presume the NEVR remains the same when the packages are moved from CR to
>> "stable"), how would this "obsolete" process happen ? I am used to the
>> fedora / fedora epel "testing" phase which is basically
>
> so lets take an example:
> 5.6/os/centos-release-5-6.0.i386.rpm
> 5.6/os/ < has no centos-release rpm >
> 5.6/CR/updates/centos-release-CR-5-7.0.i386.rpm ( which only contains
> the repo definition for the CR repo )
>
> and when there is a 5.7 :
> 5.7/os/centos-release-5-7.0.i386.rpm ( with an Obsoletes:
> centos-release-CR <= 5-7.0; and drop a copy of this rpm into the 5.6/CR/
> repo as well.
>
> Would that work ?
>
> - KB

Will centos-release-5-7.0.i386.rpm delete "centos-CR.repo" file in *any*
case, or are there possibilities that "centos-CR.repo" somehow survives?

If it's name is changed by accident, CR repository will stay enabled.
Can that affect 5.7 repository in any way by like dist-sync but in the
opposite direction 5.7 -> 5.6/CR?

I am not well versed in this type of problems so I might ask stupid
questions.


Ljubomir
_______________________________________________
CentOS-devel mailing list
CentOS-devel@centos.org
http://lists.centos.org/mailman/listinfo/centos-devel