[CentOS] rpm building and hyphens in Version tags

R P Herrold herrold at centos.org
Tue Jun 8 09:58:39 UTC 2010


On Mon, 7 Jun 2010, JohnS wrote:

> Russ, so how would you do it?  There seems to very little info on the
> subject and the things you do find on it are very thesarus like.  It
> seems in the past I have had to look in the rpm API to find certain
> things out.  One can get very confused quickly.

Again ?  'very little info' ? Goodness I've written this post 
a lot of times and Google remembers many of them -- look 
using: rpmvercmp

Following these 'thesarus like' rules is simply mechanically 
not intentionally stepping outside the 'preferred' way of 
doing things.  Sort of like those ancient Easter Island 'stone 
heads' [actually: moai], most kids these days don't know WHY 
they are there, but so long as you do not anger them they will 
not awaken and bite you ;)


What I was saying was: a hyphen in a RELEASE tag is malformed 
under the rules that RPM enforces, and the use of the explicit 
-n opton in the %setup stanza will solve the matter to get at 
an unpacked tarball.  Same goes for a hypehn in the VERSION 
tag.  The script I posted should be a general shell decoder 
ring, honoring the delimiter sets in Red Hat derived space

Debian package name, version and release decoding varies 
slightly, as it permits hyphen in a version string [1]


This 'problem' arises because the versioning (here, actually 
release numbering) of the source does not follow the OP's 
expectations on the matter.  * shrug * You cannot force an 
upstream to match your wishes and hopes.  It seems the FSF is 
silent on the matter; I seem to remember an ESR essay touching 
on best (or at least 'better') practice in the matter.  ... 
perhaps in the abortive 'trove' project doco [2] <?> We were 
hitting this issue when the LSM was trying to come up with a 
'universal' taxonomy and automated parser [3]

'rpmvercmp.c' has a set of rules that covers lots (most!!) of 
cases, but cannot cover all, as there are head to head 
inconsistencies that CANNOT be resolved under any single 
closed rule set.  One of the 'old bulls' (Peter Bowen <?>, ... 
) on the old rpm-list found a minor sort order infirmity 
perhaps eight years ago and there was a minor 'tweak' even 
within RPM.  Some history at [4] [5] The Godelian strength of 
any ruleset CANNOT contain a well-picked superset conflict


One might 'wish' that all version (and release) numbers used a 
restricted character set, explicit delimiters (or not, such as 
laternation netween letters and digits within a Version or 
Release level increment ...), and moved continuously forward 
in the seme order as the local collation sequence uses, just 
like a vehicle odometer.  I wish for a pink pony, too

But wait, as it gets worse.  Collation sequences can conflict 
as to what is a well-formed 'sequence' between various 
national languages, and within a language over time ... In 
part of my family's past there is a Danish branch, and the 
letter pair 'aa' seeming can in some cases sort after 'z' so a 
well ordered list of animal types might go either at the 
front, or the end of this list, depending on the 
pronounciation:

 	aardvark
 	bee
 	cat
 	...
 	yack
 	zebra
 	aardvark

Sadly in college they did not offer Danish, so I ended up 
learning Norwegian and make some sloppy pronounciation and 
vowel shifts when in Copenhagen to make myself understood ... 
sort of.  Actually, English seems widely understood there


The functional dominance of the english collation sequence 
seems widespread in the FOSS that I see, but I remember a huge 
fedora fight about package nameing using more than the 
ASCII-127 A-Za-z0-9[.-_] subset ... [6]

Not using embedded spaces or forward or back slashes seems 
sensible to me (as a person who swims in *nix file names -- 
Mac people regularly embed spaces and specials in file names; 
the vast confusion in doing phone support and simply 'saying' 
a URL and getting a remote person to strike: '/' vs '\' to get 
to a page is so galling, due to a certain company thinking it 
needed a special filesystem path delimiter -- but is it 
'wrong'?), but ...

I imagine a person with a first language other than english 
and who has a keyboard showing additional 'letters' on the 
key-caps thinks they should not be prevented from using those 
keys. They are right locally, but also they are wrong in 
planning for a wider audience for their software's future. 
Cognitive dissonance reigns

 	Do I contradict myself? Very well then I contradict
 	myself, (I am large, I contain multitudes.)
 		-- Walt Whitman, "Song of Myself"


Thus: Don't fight City Hall; use -n in the %setup stanze
 	and move on

[1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[2] http://catb.org/~esr/trove/trove-design.html
[3] http://www.ibiblio.org/pub/linux/LSM-TEMPLATE.html
[4] https://bugzilla.redhat.com/attachment.cgi?id=26636
[5] http://lists.infiscale.org/pipermail/caos/2003-August/000198.html 
[6] http://www.gnu.org/prep/standards/standards.html#Character-Set

I may beef this post up into a article or blog post, so I add 
a copyright here

--
end
==================================
  .-- -... ---.. ... -.- -.--
Copyright (C) 2010 R P Herrold
       herrold at owlriver.com
    My words are not deathless prose,
       but they are mine.



More information about the CentOS mailing list