From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH 8/8] xz: add xz package
Date: Sat, 13 Feb 2010 15:37:25 +0100 [thread overview]
Message-ID: <20100213143725.GP10632@mx.loc> (raw)
In-Reply-To: <1266067169.5437.18.camel@lenovo.internal.reciva.com>
On Sat, Feb 13, 2010 at 01:19:29PM +0000, Phil Blundell wrote:
>On Sat, 2010-02-13 at 13:51 +0100, Bernhard Reutner-Fischer wrote:
>> It would indeed. Can i somehow say
>> file1: SRC="http:://one.ext/one.tar.xz"
>> SRC[md5sum]=md5
>> SRC[sha256sum]=sha256
>> or, perhaps it's the basename if there was no ;name=
>> SRC[one.tar.xz.md5sum]=md5
>> SRC[one.tar.xz.sha256sum]=sha256
>> file2: SRC="git://two"
>> inc: FOO_SRC ?= SRC
>> SRC_URI += FOO_SRC
>
>I don't think this needs to be as complicated as you are making it. You
>should be able to simply move your original SRC_URI verbatim to the .inc
>file, i.e.:
>
>SRC_URI = "http://tukaani.org/xz/xz-${PV}.tar.bz2;name=xz"
>
>and then, in the individual .bb files for each version, write:
>
>SRC_URI[xz.md5sum] = ...
>
>There's no requirement for the two things to be in the same file. If
>you need to add other things like patches to the SRC_URI for a specific
>version, you can just write:
>
>SRC_URI += "file://..."
>
>in the .bb file in question.
But that would clash with _git, wouldn't it, unless, and only if this
exact sequence would be used:
.inc:=S ?= ${WORKDIR}/xz-${PV}
.inc:=SRC_URI=http
0815.bb:PV=0814+0815foo
0815.bb:require .inc
0815.bb:SRC_URI+=patch1
git.bb:S=${WORKDIR}/git
git.bb:require .inc
git.bb:SRC_URI=git
which we can obey to in this case, but it somehow feels brittle altough
it should work out fine in practise, i think.
>
>> Revised patch is attached, but:
>> it works for the 4.999beta9 version (literally, since that's how
>> upstream calls the tarball; Is this a problem with the version-naming
>> like Koon indicates?)
>
>It rather depends on what upstream are going to do next. If "4.999" is
>the number that they are using for pre-releases leading up to 5.0, and
>everything in the 4.999 series is going to be a beta (i.e. they do
>4.999.8beta, 4.999.9beta, 4.999.10beta, 5.0) then it is probably fine as
>it stands. But, if there is any risk that "4.999.9beta" might be
>followed at some point by a version called just "4.999.9", or even
>"4.999", then that would be a problem because the latter version will
>sort lower than the former.
ACK, exactly. I follow Koon on this.
>
>> since: $ ls -a ../sources/git/ctrl.tukaani.org.xz.git/
>> . .. 1 .git
>>
>> "1" ?!
>
>That is rather weird. I can't see any obvious cause for that from a
>quick inspection of the files you attached.
Just try it out, that package shouldn't interfere with any existing
recipe.
To my untrained eyes it sounds like a glitch somewhere in infrastructure
and not in those recipes, but YMV alot from mine in this respect :)
Insights?
TIA && cheers,
Bernhard
next prev parent reply other threads:[~2010-02-13 14:37 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-10 20:12 [PATCH 0/8] minor trivia; [RFC] add xz Bernhard Reutner-Fischer
2010-02-10 20:12 ` [PATCH 1/8] hwclock.sh: some more !getopt_long fixes Bernhard Reutner-Fischer
2010-02-10 20:12 ` [PATCH 2/8] autoconf: set SRC_URI name Bernhard Reutner-Fischer
2010-02-10 20:12 ` [PATCH 3/8] gmp: " Bernhard Reutner-Fischer
2010-02-10 20:12 ` [PATCH 4/8] handle xz compressed files and tarballs Bernhard Reutner-Fischer
2010-02-10 20:12 ` [PATCH 5/8] busybox: use .tar.bz2 Bernhard Reutner-Fischer
2010-02-10 20:12 ` [PATCH 6/8] busybox: remove orphaned patch checksums Bernhard Reutner-Fischer
2010-02-10 20:12 ` [PATCH 7/8] autoconf: add 2.65 Bernhard Reutner-Fischer
2010-02-10 20:13 ` [PATCH 8/8] xz: add xz package Bernhard Reutner-Fischer
2010-02-11 12:53 ` Phil Blundell
2010-02-13 12:51 ` Bernhard Reutner-Fischer
2010-02-13 13:19 ` Phil Blundell
2010-02-13 14:37 ` Bernhard Reutner-Fischer [this message]
2010-02-13 18:46 ` Phil Blundell
2010-02-13 16:14 ` BBCLASSEXTEND canadian? Bernhard Reutner-Fischer
2010-02-25 0:49 ` Tom Rini
2010-02-25 7:41 ` Bernhard Reutner-Fischer
2010-02-25 10:40 ` Richard Purdie
2010-02-25 10:39 ` Richard Purdie
2010-02-25 17:21 ` Tom Rini
2010-02-25 18:18 ` C Michael Sundius
2010-02-25 20:16 ` Richard Purdie
2010-05-28 8:37 ` Bernhard Reutner-Fischer
2010-06-01 18:41 ` Tom Rini
2010-02-11 14:06 ` [PATCH 8/8] xz: add xz package Koen Kooi
2010-02-13 12:55 ` Bernhard Reutner-Fischer
2010-02-13 13:11 ` Bernhard Reutner-Fischer
2010-03-04 14:32 ` [PATCH 7/8] autoconf: add 2.65 Marcin Juszkiewicz
2010-02-14 21:33 ` [PATCH 6/8] busybox: remove orphaned patch checksums Phil Blundell
2010-02-14 21:32 ` [PATCH 5/8] busybox: use .tar.bz2 Phil Blundell
2010-02-11 12:27 ` [PATCH 4/8] handle xz compressed files and tarballs Phil Blundell
2010-02-14 20:16 ` [PATCH 3/8] gmp: set SRC_URI name Phil Blundell
2010-02-14 21:35 ` [PATCH 2/8] autoconf: " Phil Blundell
2010-02-14 21:34 ` [PATCH 1/8] hwclock.sh: some more !getopt_long fixes Phil Blundell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100213143725.GP10632@mx.loc \
--to=rep.dot.nop@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.