From: Andreas Oberritter <obi@opendreambox.org>
To: Peter Urbanec <openembedded-devel@urbanec.net>,
"Burton, Ross" <ross.burton@intel.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] gstreamer1.0*git: Update to build current AUTOREV from master branch.
Date: Fri, 27 Feb 2015 10:35:03 +0100 [thread overview]
Message-ID: <54F03A47.8020208@opendreambox.org> (raw)
In-Reply-To: <54EFDF33.2000609@urbanec.net>
Hello Peter,
On 27.02.2015 04:06, Peter Urbanec wrote:
> On 27/02/15 08:52, Burton, Ross wrote:
>>
>> On 26 February 2015 at 17:57, Peter Urbanec
>> <openembedded-devel@urbanec.net <mailto:openembedded-devel@urbanec.net>>
>> wrote:
>>
>> -SRCREV = "127202d6f65584891dabf92be031f0d170b0e7f1"
>> +SRCREV ?= "${AUTOREV}"
>>
>>
>> I'd say that the git packages should track the tarball releases *and be
>> tested as such* so that they actually work out of the box and don't
>> break over time as upstream changes.
>
> I disagree. There's no point in having a git version of a package that
> is exactly the same as a release version. Doing so would also bring in
> all the patches specific to that release, which may not be appropriate
> for a different git revision. If you want a tested release, you would
> stick to something like gstreamer1.0*1.4.5.bb instead of choosing a git
> version.
>
>> If someone wants to make a bleeding-edge build then it's a simple change
>> to set the SRCREV to AUTOREV at the distro level.
>
> Well, as it's shaping up, that may actually not be possible in oe-core
> packages. It certainly does not work with the current gstreamer1.0*git
> recipes, because as soon as you do that you end up with infinite
> recursion when expanding SRC_URI.
>
> I think there are two main use cases for git builds. Case one is keeping
> up with the bleeding edge, which implies SRCREV="${AUTOREV}". Case two
> is freezing at a particular revision that suits you, which implies
> SRCREV="git-hash". In case one, you will probably want to run a fairly
> lean set of patches (or even none) to track the upstream. In case two,
> you could potentially have a comprehensive set of patches that will only
> apply to that revision. Both cases will be a lot easier to manage if the
> *git.bb recipe gives you a clean git repository without patches.
as far as I remember, OE-Core policy forbids AUTOREV in recipes, because
it would make network access mandatory.
The syntax for enabling it from local.conf is:
SRCREV_pn-gstreamer1.0 = "${AUTOREV}"
Regards,
Andreas
next prev parent reply other threads:[~2015-02-27 9:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-26 17:57 [PATCH] gstreamer1.0*git: Update to build current AUTOREV from master branch Peter Urbanec
2015-02-26 21:45 ` Richard Purdie
2015-02-27 2:52 ` Peter Urbanec
2015-02-26 21:52 ` Burton, Ross
2015-02-27 3:06 ` Peter Urbanec
2015-02-27 9:35 ` Andreas Oberritter [this message]
2015-02-27 12:27 ` Peter Urbanec
2015-02-27 13:58 ` Martin Jansa
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=54F03A47.8020208@opendreambox.org \
--to=obi@opendreambox.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=openembedded-devel@urbanec.net \
--cc=ross.burton@intel.com \
/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.