On Thu, 2011-03-24 at 13:19 -0400, Lamar Owen wrote: > 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. Right. Personally, given that you aren't shipping the exact binaries that upstream ship, I would say that all CentOS builds should start with a .1 added to the end of release, and then increment that for any rebuilds you need to do. I'd also have the packages provide the upstream NEVR, as well. To me that would still satisfy the "don't unnecessarily alter specfiles" mission and all of the "we changed FOO.bin but can't reflect that in FOO.src" problems go away. Of course this technically is changing the .spec ... and there _could_ be problems with 3rd party rpms requires/conflicts/obsoletes, but it seems like a much cleaner solution. Obviously changing this before CentOS-7 would be complete insanity, but I think it's worth considering for then. > > 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). Right, sorry, I worded my question badly. What I meant to ask is: I understand that you probably rebuild the same NEVRAs "a lot" during the initial distro. creation, as you are guessing about what the build environment of each SRPM was. I also understand that this happens "sometimes" for updates, Eg. libtalloc or util-linux, but ... how often is this a problem for updates? Is it 1-2 packages a year, 1-2 a month, more? > > 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. Personally I doubt a beta would be useful anyway. As I don't think people want a CentOS beta released quickly ... they "just" want a CentOS release released quickly, and if you release a beta (esp. with the same NEVRAs as release) they'll either ignore it or treat it as a release. > 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 Yeh, this is the above "we change FOO.bin, but don't want to change FOO.src" problem. I understand, but I'm still tempted to say "don't do that then".