[CentOS-devel] Why not a fusion between CentOS and SL?

[Lamar Owen]

On Thursday, March 24, 2011 11:58:03 am James Antill wrote:
>  This is kind of a unique situation, in that it's pretty well accepted
> that if you are rebuilding for any reason you need to change at least
> the release in some way.

The problem, at least for CentOS, becomes the stated policy of no changes to the upstream source RPM unless absolutely necessary.  Changing the release is a change to the upstream source RPM, and doesn't qualify as absolutely necessary.

>  I kind of understand why you don't want to, but I'm not sure it's worth
> the problem of having M versions of a particular NEVRA. Does this happen
> anytime after initial distro. creation?

It would happen any time a source RPM would have to be rebuilt due to binary linkage differences; the initial build(s) that had the wrong linkage version(s) and the final, binary compatible confirmed build would have the same EVR but different contents and different dependencies.  As long as a 'cannot change the source RPM' policy is to be followed this will be true.  This is true specifically for the problem RPM with the wrong libtalloc dependency that has been mentioned, for update 6 of C5 (I really, really, really strongly dislike the use of a minor version to reflect the upstream's quarterly large updates).

>  As above, we currently mostly only look at NEVRA for identifying
> packages in any part of yum.
>  For rpmdbv's we also look at the checksum, so I had thought about doing
> something so you could more easily "reinstall" anything with changed
> checksums:
[snip code segment]
>  Probably the most significant downside is that you can't sort based on
> that, you can only tell that X is different from Y not which is
> preferred but then I'd _really_ want to discourage people publishing
> multiple NEVRAs that are identical ... and one assumes that when you are
> doing your builds you rarely (if ever?) want to go backwards.

Methinks that is the strongest argument against a CentOS alpha or beta being published, since by definition there are going to be exactly that: two or more packages with identical NEVRA tuples with different contents and different checksums.  I say by definition since it is one of the stated goals of CentOS to not change the upstream source package in any way unless a trademark issue or in the case of kernel signing where it's necessary.  If you can't change the source RPM you can't change NEVRA.  Unless you want to tag every single RPM in the distribution with a distribution tag.....or a repository tag....

Please read Connie Sieh's first paragraph, and Troy's immediately previous paragraph, in a December 17, 2010 posting to scientific-linux-devel, found in their archives at:
http://listserv.fnal.gov/scripts/wa.exe?A2=ind1012&L=scientific-linux-devel&T=0&I=-3&P=2967

And while I could easily quote that here, I think reading the whole e-mail, including the quoted lines from Troy, will be beneficial.

>  In theory we could also use "buildtime", but I'm very wary of making
> that into a minor release id as it would encourage the multiple NEVRAs
> problem and it is much less linear in other distributions (although
> they'd tend to respect NEVRA :).

Well, other distributions have control of their own source RPM's NEVRA; rebuilding from source RPM by default reliquishes control of NEVRA to upstream.  So if you don't get the build right on the first go, you are going to have more than one package with the same NEVRA, and either buildtime or checksum will show the  difference; buildtime is more desireable, I would think.  If the distribution is being built out of an SCM or full buildsystem like koji, and the upstream is not already built into a NEVRA-frozen source RPM, then you don't have this problem.  This is only a problem when you're rebuilding from somebody else's source RPMs. 

Or when you're maintaining an upstream RPM set and find out that you didn't update before churning out that last build..... you get a quandary of having to bump release because you forgot to issue yum update before building.  With mock, of course, that problem goes away, but I maintained RPMs before mock (or mach) existed, and I tried to always bump release for every single build, regardless.  Of course, then you have to put in a changelog line and explain the rebuild.... and many times it was just tempting to not bump release and just throw the rebuild up there, slipstreaming it into the ftp site....

>  Also worth noting is that the one NEVRA dup. with different checksums I
> can see on F13 is libjingle in updates and fedora-chromium ... and those
> have the same buildtime (I assume spot just resigned it).

Could be.