[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [rhelv6-list] rebuilt package not showing selected for update



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:herrold 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]