From: Philip Balister <philip@balister.org>
To: openembedded-devel@lists.openembedded.org
Cc: Martin Jansa <martin.jansa@gmail.com>
Subject: Re: [meta-oe][PATCH] smartmontools: import from OE classic
Date: Fri, 03 May 2013 11:15:28 -0400 [thread overview]
Message-ID: <5183D490.8050804@balister.org> (raw)
In-Reply-To: <20130503150917.GB3187@jama>
[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]
On 05/03/2013 11:09 AM, Martin Jansa wrote:
> On Fri, May 03, 2013 at 03:42:30PM +0100, Paul Eggleton wrote:
>> On Friday 03 May 2013 16:30:17 Nicolas Dechesne wrote:
>>> On Fri, May 3, 2013 at 4:10 PM, Koen Kooi <koen@dominion.thruhere.net>wrote:
>>>>> I agree we should try to keep only one version of each recipe in
>>>>> software
>>>>> layers, however I figure it makes it easier for people to carry their
>>>>> own
>>>>> versions of recipes in distro layers (particularly older, which may be
>>>>> required in certain circumstances) if we do keep inc files where they
>>>>> already exist.
>>>
>>>> Can people raise their hand if they want to have a different version of
>>>> smartmontools in their layer?
>>>
>>> i think it would be nice to have a policy for that. i am going to send a
>>> couple of recipes for new components, and it would be good to know what's
>>> the agreed 'policy' for .inc file.
>>
>> We probably should have a stated policy, yes. AFAIK the current perhaps
>> unstated policy is to keep the inc file if it existed in OE-Classic.
>
> I don't have strong opinion about keeping/loosing .inc files, but
> I've removed couple of .inc files when importing stuff from OE-Classic
> in cases where .inc is relatively short (like in smartmontools).
>
> I would keep .inc when it's reused in different recipes or really
> long/complicated (like mesa.inc).
>
> We also have policy that there is only one version per recipe if
> possible.
I agree with Martin. I've dropped some .inc files for recipes I worry
about also.
Philip
>
>>> in fact, it's not even clear to me why
>>> have .inc file is easier to carry different version in distro layers. well
>>> it's just a 'large' recipe to carry over..
>>
>> If you carry over the whole recipe rather than "require recipes-
>> xyz/foo/foo.inc", then you won't get any improvements to the non-version-
>> specific parts of the recipe when the base layer updates in the future.
>>
>> Alternatively if you "require recipes-xyz/foo/foo_6.5.bb" because there is no
>> .inc, then your recipe will definitely break the next time the recipe in the
>> base layer is upgraded, plus you may have to override more parts of the recipe
>> that are specific to a different version than the one you are building.
>>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 567 bytes --]
next prev parent reply other threads:[~2013-05-03 15:33 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-26 20:39 [meta-oe][PATCH] smartmontools: import from OE classic Nicolas Dechesne
2013-04-26 21:41 ` Koen Kooi
2013-04-27 8:24 ` Paul Eggleton
2013-04-27 10:34 ` Philip Balister
2013-04-27 11:13 ` Paul Eggleton
2013-04-29 6:40 ` Nicolas Dechesne
2013-05-03 14:00 ` Nicolas Dechesne
2013-05-03 14:35 ` Paul Eggleton
2013-05-03 14:40 ` Koen Kooi
2013-05-03 14:48 ` Paul Eggleton
2013-05-03 14:10 ` Koen Kooi
2013-05-03 14:30 ` Paul Eggleton
2013-05-03 14:39 ` Koen Kooi
2013-05-03 14:30 ` Nicolas Dechesne
2013-05-03 14:42 ` Paul Eggleton
2013-05-03 15:09 ` Martin Jansa
2013-05-03 15:15 ` Philip Balister [this message]
2013-05-06 8:19 ` Nicolas Dechesne
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=5183D490.8050804@balister.org \
--to=philip@balister.org \
--cc=martin.jansa@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.