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