[CentOS-devel] Confusing package versioning

R P Herrold

herrold at owlriver.com
Fri May 6 03:43:32 UTC 2011


On Thu, 5 May 2011, Les Mikesell wrote:

> Yes, I took that as an observation, not an opinion that 
> needed to be kept private...  Can anyone think otherwise?

Certainly 'anyone' can think otherwise; I do, for example, for 
upon the following analyses:

Procedural: They (hughesjr and singh) said their piece, and 
they shut up, unlike many here who need entertainment of 
trolling or badgering endlessly -- This is: talkers vs. doers 
all over again.  Eventually the 'doers' ignore the 'talkers' 
and return to their work

Substantive: Upstream has a mode using Z streams, %{_isa} 
tags, mal-placed %{dist} tags, famously had several people 
holding @redhat email address holders argue against %{repo} 
tags in the EPEL context, and other mechanisms that do not all 
work with a strict NEVR resolution by rpmlib and rpmvercmp 
[ie, a simple 'yum update' model]; formerly package dependency 
computations were done against a Oracle database backend in 
the RHN model on the server side

'Ned Slider' points out (correctly, to my thinking for 
reasons, infra) that the Rel tag is sometimes comprised of an 
extension containing the %{dist} tag -- and THEN OTHER STUFF 
[seeming a Z channel indicator, or ${_isa}] expansion, or 
simply a manual edit to the RIGHT of a macro-expanded tag]

Eventually rpmvercmp as it walks through the sequential 
element and sub-element comparisons it does, MAY reach such, 
or it may NOT and it MAY matter in determining on an automatic 
basis which of two pakages is intended to be 'later'

It is rare, but I have seen examples, particularly in the 6 
sources, and in RawHide, as there are thousands of people 
managing these tags in the latter and 'stuff' happens.  There 
are some really ** wrong ** Rel tags containing Ver 
information, in some of the 'R' statistical add-on packages 
out of the upstream's Enterprise side, from a year back or so 
[and indeed the 'R' add-on modules practice contemplates 
slip-streamed versions all bearig the same source tarball 
versioning -- making matters even worse] -- I repackaged 
around the upstream's 'errors', and track several R adjunct 
archives CRAN, Bio, R-Forge, 'looking' for changes using 
mirroring and daily md5sum diffs to spot such 
'slip-streaming', to get my builders to work for some 
customers of supplemental content

But at the end of the day, these choices belong to the 
upstream.  Their sources, and their choices.  CentOS does not 
own them, and does not control them; it can only react to them 
under our touchstone rule 'forever' of a 'strict rebuild, with 
minimal changes for the updater, trademark elidement, and 
branding changes'

Perhaps the Rel 'cruft' is conscious, perhaps due to poor 
internal communication of how a malformed Rel entry breaks yum 
or other naiive dependency solvers; perhaps simply unknowing 
due to the computational complexity of the problem-space and 
running multiple products -- it does not matter which applies, 
because further ...

CentOS 'flattens' that N dimensional space those product 
variations represent; sometimes, this means that ** any ** EVR 
comparison can be 'wrong' from the rpmlib point of view, 
cpmpared to what may be internally desired by a sysadmin.

And it does no good to get 'exercised' about it -- testing 
shows the issue; Lamar's example seems to be correct upon 
inspection, but darn it, it is just not worth getting wound up 
on -- Add an 'exclude=' to hold out an error (tin his example, 
ntp, rpm -e it, and then yum the false to reality 'earlier but 
correct' NEVR package right back in --- no need for tears.

Why I remember that the former RHL days that the community's 
Postgresql packager tried to accomodate all schema and store 
procedure unloads and reloads, so that a person using just RPM 
to upgrade across a major release did not even need to read 
release notes or take backups -- too much sleep was lost on 
this task, trying to solve that riddle within a Turing 
complete language space

This is why, rather, one has a testbed to burn up, before 
applying updates to critical or production systems, and 
'change control' processes permitting roll-backs to prior 
images if something unexpected goes horribly wrong

If a person wants to have someone listen to them carp about 
this; or to take, test and manage backups; or to have a 
deterministic path solved on your behalf, there are vendors 
who will sell such services to all comers at varying levels of 
quality -- but the CentOS project is not such a vendor

It also means (under Godel's theorem, assuming either a 
random, or a malicious party feeding 'noise' into the system) 
that no single set of patches ** can ** work in all cases, 
both for the foregoing reasons, and because this is a moving 
target requiring perfect predictive future knowledge of the 
EVR changes a given package going to take

Read 'Godel, Escher and Bach' for more context --- 'tea 
leaf reading' the upstream is out of scope here

-- Russ herrold



More information about the CentOS-devel mailing list