On 02/22/2011 07:23 PM, Leonard den Ottolander wrote:
Hi Greg,
On Sat, 2011-02-19 at 09:23 -0700, Greg Bailey wrote:
OK, this morning's programming project is a python script to automatically generate your list. I get:
I hadn't spotted that you already solved this in python. With some shell scripting I come to essentially the same result. (My hit on zsh is a last iteration bug :)
I have one addition: comps-4WS-0.20110202. Not sure what to make of anaconda-product-4-2WS.
initscripts-7.93.35-1.el4_8.src.rpm kdelibs-3.3.1-17.el4_8.1.src.rpm pidgin-2.6.6-5.el4_8.src.rpm seamonkey-1.0.9-66.el4_8.src.rpm squirrelmail-1.4.8-5.el4_8.8.src.rpm
I think these are false positives.
indexhtml-4.1-1.src.rpm
Rather distro dependent but it might need updating as well.
Everything else on our lists matches afaict.
Regards, Leonard.
Thanks guys.
The comps files are created at distro spin and will not be updated as we will not be re-spinning the distro or ISOs. comps is also used in a different way by RHN, which is why upstream rebuilt it.
The anaconda product RPM is also not one that we need to do as upstream has WS, ES, AS, etc versions that they charge different $$$ amount for. All of the others are subsets of AS, which is what our SRPM anaconda-product-4.0-2.centos4.src.rpm is based on. That contains all upstream el4 packages.
You guys are also correct that the .dist tag (.el4, .el4_x, etc.) is not necessarily critical. Sometimes within a release of a product, upstream will work on a new version of a package that will be part of the next "point release" and also will issue fixes to the package before the point release by using a different dist tag. So, abc-1.0.0-1.el4.i386.src.rpm will get an update to abc-1.0.0-2.el4.i386.src.rpm for a 4.9 release (as an example). If, while they are testing abc-1.0.0-2, they need to release a bug fix to abc-1.0.0-1 then they will change the dist tag to el4_8 and add a .1 after the tag. So it would become abc-1.0.0-1.el4_8.1.src.rpm ... this is because they already have a 1.0.0-2 somewhere in the release system. We try to be consistent with the dist tags, but sometimes they slip through with a different version. This in no way impacts the code or the binary compatibility of the RPM.
As far as the rest of the SRPMS are concerned, I need to look at both those lists one by one, but most (if not all) of those SRPMS are from arches other than i386 and x86_64, so will not be on my list of packages to build. I will post info about each one separately in another mail.
Thanks for taking the time to help me verify the 4.9 release.