According to http://www.rpm.org/api/4.4.2.2/specfile.html a Version: tag can contain a hyphen, as the tarball for the source I am compiling is named 2.3-pre4 etc.
When I try to build it I get an error about the illegal char?
Anyone know about the discrepancy between the docs and RHEL's rpmbuild? Without recreating a new tarball and bungling the name how does one gracefully handle this?
Thanks! jlc
On Mon, 2010-06-07 at 22:20 +0000, Joseph L. Casale wrote:
According to http://www.rpm.org/api/4.4.2.2/specfile.html a Version: tag can contain a hyphen, as the tarball for the source I am compiling is named 2.3-pre4 etc.
When I try to build it I get an error about the illegal char?
Anyone know about the discrepancy between the docs and RHEL's rpmbuild? Without recreating a new tarball and bungling the name how does one gracefully handle this?
Thanks! jlc
--- Ok Special Attention here:
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/inotify-tools-3.13-3.el5-root-ethan Wrote: /home/ethan/rpmbuild/SRPMS/inotify-tools-3.13-3.el5.src.rpm Wrote: /home/ethan/rpmbuild/RPMS/i386/inotify-tools-3.13-3.el5.i386.rpm Wrote: /home/ethan/rpmbuild/RPMS/i386/inotify-tools-devel-3.13-3.el5.i386.rpm Wrote: /home/ethan/rpmbuild/RPMS/i386/inotify-tools-debuginfo-3.13-3.el5.i386.rpm ############################################################################ inotify-tools/spec ############################################################################ Name: inotify-tools Version: 3.13 Release: 3%{?dist} ## Here is you wanted `-`... ## Summary: Command line utilities for inotify
Release: pre4%{?dist}
John
Ok Special Attention here:
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 Checking for unpackaged file(s): /usr/lib/rpm/check-files /var/tmp/inotify-tools-3.13-3.el5-root-ethan Wrote: /home/ethan/rpmbuild/SRPMS/inotify-tools-3.13-3.el5.src.rpm Wrote: /home/ethan/rpmbuild/RPMS/i386/inotify-tools-3.13-3.el5.i386.rpm Wrote: /home/ethan/rpmbuild/RPMS/i386/inotify-tools-devel-3.13-3.el5.i386.rpm Wrote: /home/ethan/rpmbuild/RPMS/i386/inotify-tools-debuginfo-3.13-3.el5.i386.rpm ############################################################################ inotify-tools/spec ############################################################################ Name: inotify-tools Version: 3.13 Release: 3%{?dist} ## Here is you wanted `-`... ## Summary: Command line utilities for inotify
Release: pre4%{?dist}
That's not quit working as expected, my tarball is specifically named sarg-2.3-pre4.tar.gz and so when rpmbuild extracts it, it creates a 'sarg-2.3-pre4' dir and it expects to cd into it.
The release tag only comes into play with the final rpm naming.
rpm.org suggests in another doc that if epoch is defined, then you cant use hyphens, buts that's not obviously the case...
I am sure there is a better way to do this, but to get it into the correct directory, I used: %setup -n sarg-2.3-pre4
To control the final rpm name, I could use _build_name_fmt but I don't know all the ramifications of this one yet, so I let it name just sarg-2.3-1.
Hopefully I stumble across the right way...
Thanks for helping! jlc
On Mon, 2010-06-07 at 22:20 +0000, Joseph L. Casale wrote:
Ok a follow up... What you want is the release tag not the version because it will not work in the version tag.
Why I do not know. I tried again with another src.rpm and has to be release tag for sure. Bombs out with an illegal tag.
John
On Mon, 7 Jun 2010, Joseph L. Casale wrote:
According to http://www.rpm.org/api/4.4.2.2/specfile.html a Version: tag can contain a hyphen, as the tarball for the source I am compiling is named 2.3-pre4 etc.
ehh?
Names must not include whitespace and may include a hyphen '-' (unlike version and release tags).
That is, version and release are UNLIKE name. name MAY have a hyphen. by inference (and as you have seen), version and release may not.
The computational load from extracting this information from a package with --querytags is VERY HIGH, compared to simple textual processing
[herrold@new bin]$ time rpm -qp graphviz-2.8-1.sl.src.rpm --qf \ '%{name} \t %{version} \t %{release} \n' 2> /dev/null graphviz 2.8 1.sl
real 0m0.030s user 0m0.019s sys 0m0.011s [herrold@new bin]$ time ./split-rpm.sh graphviz-2.8-1.sl.src.rpm Tgt.: graphviz-2.8-1.sl.src.rpm Name: graphviz Ver.: 2.8 Rel.: 1.sl
real 0m0.017s user 0m0.004s sys 0m0.013s [herrold@new bin]$
#!/bin/sh # # split-rpm.sh # an RPH original released under GPLv3 # Copyright (c) 2010 R P Herrold, Columbus, OH # info@owlriver.com # [ "x${1}" = "x" ] && { echo "Usage: $0 (rpmpackage_name)" 1>&2 exit 1 } REL=`echo "$1" | rev | cut -d- -f 1 | cut -d'.' -f 3- | rev ` VER=`echo "$1" | rev | cut -d- -f 2 | rev` NAM=`echo "$1" | rev | cut -d- -f 3- | rev` echo "Tgt.: ${1}" echo "Name: ${NAM}" echo "Ver.: ${VER}" echo "Rel.: ${REL}" #
-- Russ herrold
ehh?
Names must not include whitespace and may include a hyphen '-' (unlike version and release tags).
That is, version and release are UNLIKE name. name MAY have a hyphen. by inference (and as you have seen), version and release may not.
Heh, well I had my head so far up my arse on that one it was back on top:)
How would you handle this case? As per my last email , I used a -n in the %setup to cd into the right dir but I am left with improperly named and versioned rpms as they don't actually match the source!
Thanks guys, jlc
On Tue, 8 Jun 2010, Joseph L. Casale wrote:
ehh?
Names must not include whitespace and may include a hyphen '-' (unlike version and release tags).
That is, version and release are UNLIKE name. name MAY have a hyphen. by inference (and as you have seen), version and release may not.
How would you handle this case? As per my last email , I used a -n in the %setup to cd into the right dir but I am left with improperly named and versioned rpms as they don't actually match the source!
A %{dist} tag, or the variations, have a long and muddy history, not even interesting to the participants of those wars. My only advice is: Don't fight city hall here
-- Russ herrold
On Mon, 2010-06-07 at 21:47 -0400, R P Herrold wrote:
On Tue, 8 Jun 2010, Joseph L. Casale wrote:
ehh?
Names must not include whitespace and may include a hyphen '-' (unlike version and release tags).
That is, version and release are UNLIKE name. name MAY have a hyphen. by inference (and as you have seen), version and release may not.
How would you handle this case? As per my last email , I used a -n in the %setup to cd into the right dir but I am left with improperly named and versioned rpms as they don't actually match the source!
A %{dist} tag, or the variations, have a long and muddy history, not even interesting to the participants of those wars. My only advice is: Don't fight city hall here
-- Russ herrold
--- 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.
John
Given that the rpm NVREA bears no relation to the name of the source tarball (indeed nothing is required in SOURCES to build an rpm) how about just removing the -pre4 from the archive name when saving it in SOURCES? You can still put pre4 in the release tag of the tarball. As for the setup macro tell it not to change into the directory and find the right directory name via ls... or don't use setup at all and cp tar etc yourself.
James
Sent from Android mobile
On Jun 8, 2010 4:26 AM, "JohnS" jses27@gmail.com wrote:
On Mon, 2010-06-07 at 21:47 -0400, R P Herrold wrote:
On Tue, 8 Jun 2010, Joseph L. Casale 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.
John
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists....
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@owlriver.com My words are not deathless prose, but they are mine.
On Tue, 2010-06-08 at 05:58 -0400, R P Herrold wrote:
Again ? 'very little info' ? Goodness I've written this post a lot of times and Google remembers many of them -- look using: rpmvercmp
About 9,490 results (0.35 seconds) and on so little of them are correct and up to date.
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
Saw the script.
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
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]
Well you have the solution to that. As in since you seem to like Anthropology and Family History. Predictions. Prediction sequences can and should derive the correct version for upgrade. All though this is only really done in databases like Postgres and MySQL via API. R may seem to be a good fit. If nothing else theres nothing wrong with some fancy inline .asm. Would it work? I do not know. I would have to get hacking. This does work with Genealogy btw.
Teaser: my status update uses an assembly Kernel API.
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 ...
Yes a huge problem.
Thus: Don't fight City Hall; use -n in the %setup stanze and move on
Nice post. Would like to see more like this from you.
John
On Wed, 9 Jun 2010, JohnS wrote:
Thus: Don't fight City Hall; use -n in the %setup stanze and move on
Nice post. Would like to see more like this from you.
The whole CentOS crew is picked up at: http://planet.centos.org/
and these are people who are literate, and hold strong opinions that they can express well. At one point, I went through and editted the aggregator to only pick up content tagged with 'centos' as we had complaints about side opinion matter, but the home feed URLs of each have a fine collection of such 'good stuff'
I seem to have anticipated the US CERT email-republished advisory on the Flash cross-scripting attack being actively exploited with mine yesterday on 'reading the logs: http://orcorc.blogspot.com/2010/06/reading-logs.html
I posted in the morning, and got the June 8 update release in my email that afternoon: http://www.adobe.com/support/security/advisories/apsa10-01.html
The matter is critical indeed, because a person performing actions exposing their unit to potentially hostile third party content as a root or administrator right account can become invisibly compromised
There is presently another active one using PDFs as a carrier, rather than Flash, that I see in my logs as well (behind a couple of layers of one way 'lobster trap' firewalls, but clearly able to be invisibly 'pulled through' by web / PDF browsers viewing 'trapped' content)
-- Russ herrold
On Wed, 2010-06-09 at 11:40 -0400, R P Herrold wrote:
On Wed, 9 Jun 2010, JohnS wrote:
Thus: Don't fight City Hall; use -n in the %setup stanze and move on
Nice post. Would like to see more like this from you.
The whole CentOS crew is picked up at: http://planet.centos.org/
and these are people who are literate, and hold strong opinions that they can express well. At one point, I went through and editted the aggregator to only pick up content tagged with 'centos' as we had complaints about side opinion matter, but the home feed URLs of each have a fine collection of such 'good stuff'
I seem to have anticipated the US CERT email-republished advisory on the Flash cross-scripting attack being actively exploited with mine yesterday on 'reading the logs: http://orcorc.blogspot.com/2010/06/reading-logs.html
I posted in the morning, and got the June 8 update release in my email that afternoon: http://www.adobe.com/support/security/advisories/apsa10-01.html
The matter is critical indeed, because a person performing actions exposing their unit to potentially hostile third party content as a root or administrator right account can become invisibly compromised
There is presently another active one using PDFs as a carrier, rather than Flash, that I see in my logs as well (behind a couple of layers of one way 'lobster trap' firewalls, but clearly able to be invisibly 'pulled through' by web / PDF browsers viewing 'trapped' content)
I smell a custom compiled ip tables with tarpit? While indeed all that is good info for a lot of people I was not referring to any of that above. I have been familiar with all that for a long time. If missed somehow I get an anonymous mail...As I see all that is posted in CentOS Planet....
" Would like to see more of this from you" Was intended to be more like: Good to see you are being nice and informative. Instead of your normal like saying cmovCC! %EBX...
John
-
James Hogarth -
JohnS -
Joseph L. Casale -
R P Herrold