FAQ
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

Search Discussions

  • JohnS at Jun 7, 2010 at 6:48 pm

    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
  • Joseph L. Casale at Jun 7, 2010 at 9:08 pm

    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
  • JohnS at Jun 7, 2010 at 6:55 pm
    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
  • R P Herrold at Jun 7, 2010 at 8:23 pm

    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 at 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 at 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 at new bin]$

    #!/bin/sh
    #
    # split-rpm.sh
    # an RPH original released under GPLv3
    # Copyright (c) 2010 R P Herrold, Columbus, OH
    # info at 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
  • Joseph L. Casale at Jun 7, 2010 at 9:14 pm

    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
  • R P Herrold at Jun 7, 2010 at 9:47 pm

    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
  • JohnS at Jun 7, 2010 at 11:27 pm

    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
  • James Hogarth at Jun 8, 2010 at 3:31 am
    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" 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 at centos.org
    http://lists....
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20100608/419481d0/attachment.html
  • R P Herrold at Jun 8, 2010 at 5:58 am

    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&636
    [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.
  • JohnS at Jun 9, 2010 at 10:09 am

    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
  • R P Herrold at Jun 9, 2010 at 11:40 am

    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
  • JohnS at Jun 9, 2010 at 1:16 pm

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcentos @
categoriescentos
postedJun 7, '10 at 6:20p
activeJun 9, '10 at 1:16p
posts13
users4
websitecentos.org
irc#centos

People

Translate

site design / logo © 2022 Grokbase