Thanks for the details - it is a lot to digest, but in general makes sense.
Related to "dist", this is what I did: rpmbuild --define 'dist .el6.custom' -bb ksh.spec Where previously I would define dist as ".el6" or whatever the distribution happened to be. Kevin -----Original Message----- From: R P Herrold [mailto:herr...@owlriver.com] Sent: Friday, December 10, 2010 12:19 PM To: Collins, Kevin [BEELINE] Cc: rhelv6-list@redhat.com Subject: rebuilt package not showing selected for update On Fri, 10 Dec 2010, Collins, Kevin [BEELINE] wrote: > So, are you saying that this tool is only comparing the strings and not > looking at any packages? After a bit of playing, that would seem to be > the case... which at least lets me test for what I think is a "smart" > way to name my rebuild packages. There was a minor change in the logic some years ago, but the comparison method of rpmvercmp.c has been quite stable see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=178798 This may be of interest as well: http://blog.client9.com/2010/04/comparing-rpm-version-strings-rpm.html which has a long set of comment about the edge cases by a author who knows those dark and twisty corners well http://client9.com/downloads/rpmvercmp.c is out there from that blogger as well A safe working rule is to do the NEVR [Name, Epoch, Version, Release] comparison step by step as string comparisons; within each sub-element of NEVR, every time a separator [a non-alpha, and non-numeral digit; with "." the most commonly one seen one] is encountered, treat it as a sub-element separator to signal the end of a STRING comparand Remember: We are not dealing with numbers (int's, floats, octals, hex's, whatever) here (with all the problems of leading or implied leading zeroes and radix markers) If a local package is present, rpm can query the package for its element values with the --qf sub-option Textually as when inferring values from a flat listing of a remote archive, NEVR elements may be approximated by counting back right to left separating by each hyphen, and in the case of Release, discarding the last two '.' separated elements REL=` echo "peach-3-4.src.rpm" | rev | awk -F- {'print $1'} | cut -d. -f3- | rev ` VER=` echo "peach-3-4.src.rpm" | rev | awk -F- {'print $2'} | rev ` NAM=` echo "peach-3-4.src.rpm" | rev | awk -F- {'print $3'} | rev ` and REL will end up with "4", VER with "3", NAM with "peach" -- sans the '"' of course, but shown here to emphasize that these may look like numbers but are not Epoch is the red-headed odd case, and is not customarily displayed in file listings for historical reasons apple-3-4.src.rpm is unequal to peach-3-4.src.rpm reason: Name "apple" < "peach" --------------------------- 1:apple-3-4.src.rpm also sometimes seen in the notation: apple-1:3-4.src.rpm -- the LHS of the colon back to the next non-decimal-numeral item is older (less) than 2:apple-3-4.src.rpm reason: Epoch "1" < "2" --------------------------- You mentioned what looked like a %{dist} suffix "el6" to "el6.custom" on a Release field, and that would cause a otherwise seemingly otherwise identical package rebuild from the same sources, but with %{dist} NOT %{nil} to compare as a later item than the one with the nil dist tag [I understand you did a manual .spec file edit, but defining the 'dist' field is perhaps a better way to manage this, as most SRPMs from Red Hat derived space carry variants of this] able-1-2.src.rpm is older than able-1-2.custom.src.rpm -- Russ herrold _______________________________________________ rhelv6-list mailing list rhelv6-list@redhat.com https://www.redhat.com/mailman/listinfo/rhelv6-list
