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