[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