Patchwork [meta-oe] smartmontools: import from OE classic

login
register
mail settings
Submitter Nicolas Dechesne
Date April 26, 2013, 8:39 p.m.
Message ID <1367008757-18667-1-git-send-email-nicolas.dechesne@linaro.org>
Download mbox | patch
Permalink /patch/48961/
State Superseded
Headers show

Comments

Nicolas Dechesne - April 26, 2013, 8:39 p.m.
Import smartmontools recipe from OE classic, and updated to upstream v5.40.

Also added cosmetic changes in the recipe: INC_PR support and homepage.

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
---
 meta-oe/recipes-support/smartmontools/smartmontools.inc     | 10 ++++++++++
 meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb |  5 +++++
 2 files changed, 15 insertions(+)
 create mode 100644 meta-oe/recipes-support/smartmontools/smartmontools.inc
 create mode 100644 meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb
Koen Kooi - April 26, 2013, 9:41 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 26-04-13 22:39, Nicolas Dechesne schreef:
> Import smartmontools recipe from OE classic, and updated to upstream
> v5.40.
> 
> Also added cosmetic changes in the recipe: INC_PR support and homepage.
> 
> Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> --- 
> meta-oe/recipes-support/smartmontools/smartmontools.inc     | 10
> ++++++++++ meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb |
> 5 +++++ 2 files changed, 15 insertions(+) create mode 100644
> meta-oe/recipes-support/smartmontools/smartmontools.inc create mode
> 100644 meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb
> 
> diff --git a/meta-oe/recipes-support/smartmontools/smartmontools.inc
> b/meta-oe/recipes-support/smartmontools/smartmontools.inc new file mode
> 100644 index 0000000..6f23055 --- /dev/null +++
> b/meta-oe/recipes-support/smartmontools/smartmontools.inc @@ -0,0 +1,10
> @@ +SECTION = "console/utils" +DESCRIPTION = "Control and monitor storage
> systems using S.M.A.R.T." +HOMEPAGE =
> "http://smartmontools.sourceforge.net/" +LICENSE = "GPLv2" 
> +LIC_FILES_CHKSUM =
> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" +INC_PR = "r1"

Drop that

> + +SRC_URI =
> "${SOURCEFORGE_MIRROR}/smartmontools/smartmontools-${PV}.tar.gz" + 
> +inherit autotools diff --git
> a/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb
> b/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb new file
> mode 100644 index 0000000..93dc4db --- /dev/null +++
> b/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb @@ -0,0
> +1,5 @@ +require smartmontools.inc +PR = "${INC_PR}.1"

And drop that.

And do you really need a .inc?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFRevSRMkyGM64RGpERArE1AJ0XBvO7c35yipb1VMI1/GCwgOzCkQCeJQF1
z4Yu+V8MtCJnn0DZKNyIywk=
=Jq0r
-----END PGP SIGNATURE-----
Paul Eggleton - April 27, 2013, 8:24 a.m.
On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Op 26-04-13 22:39, Nicolas Dechesne schreef:
> > Import smartmontools recipe from OE classic, and updated to upstream
> > v5.40.
> > 
> > Also added cosmetic changes in the recipe: INC_PR support and homepage.
> > 
> > Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> ---
> > meta-oe/recipes-support/smartmontools/smartmontools.inc     | 10
> > ++++++++++ meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb |
> > 5 +++++ 2 files changed, 15 insertions(+) create mode 100644
> > meta-oe/recipes-support/smartmontools/smartmontools.inc create mode
> > 100644 meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb
> > 
> > diff --git a/meta-oe/recipes-support/smartmontools/smartmontools.inc
> > b/meta-oe/recipes-support/smartmontools/smartmontools.inc new file mode
> > 100644 index 0000000..6f23055 --- /dev/null +++
> > b/meta-oe/recipes-support/smartmontools/smartmontools.inc @@ -0,0 +1,10
> > @@ +SECTION = "console/utils" +DESCRIPTION = "Control and monitor storage
> > systems using S.M.A.R.T." +HOMEPAGE =
> > "http://smartmontools.sourceforge.net/" +LICENSE = "GPLv2"
> > +LIC_FILES_CHKSUM =
> > "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" +INC_PR = "r1"
> 
> Drop that

It would help for the sake of the uninitiated if you specified what to drop, 
since your mail client has wrapped the quoted text incorrectly.

> > + +SRC_URI =
> > "${SOURCEFORGE_MIRROR}/smartmontools/smartmontools-${PV}.tar.gz" +
> > +inherit autotools diff --git
> > a/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb
> > b/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb new file
> > mode 100644 index 0000000..93dc4db --- /dev/null +++
> > b/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb @@ -0,0
> > +1,5 @@ +require smartmontools.inc +PR = "${INC_PR}.1"
> 
> And drop that.
> 
> And do you really need a .inc?

Are we removing inc files if they were present in OE Classic? First I've heard 
if we are...

Cheers,
Paul
Philip Balister - April 27, 2013, 10:34 a.m.
On 04/27/2013 04:24 AM, Paul Eggleton wrote:
> On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Op 26-04-13 22:39, Nicolas Dechesne schreef:
>>> Import smartmontools recipe from OE classic, and updated to upstream
>>> v5.40.
>>>
>>> Also added cosmetic changes in the recipe: INC_PR support and homepage.
>>>
>>> Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org> ---
>>> meta-oe/recipes-support/smartmontools/smartmontools.inc     | 10
>>> ++++++++++ meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb |
>>> 5 +++++ 2 files changed, 15 insertions(+) create mode 100644
>>> meta-oe/recipes-support/smartmontools/smartmontools.inc create mode
>>> 100644 meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb
>>>
>>> diff --git a/meta-oe/recipes-support/smartmontools/smartmontools.inc
>>> b/meta-oe/recipes-support/smartmontools/smartmontools.inc new file mode
>>> 100644 index 0000000..6f23055 --- /dev/null +++
>>> b/meta-oe/recipes-support/smartmontools/smartmontools.inc @@ -0,0 +1,10
>>> @@ +SECTION = "console/utils" +DESCRIPTION = "Control and monitor storage
>>> systems using S.M.A.R.T." +HOMEPAGE =
>>> "http://smartmontools.sourceforge.net/" +LICENSE = "GPLv2"
>>> +LIC_FILES_CHKSUM =
>>> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f" +INC_PR = "r1"
>>
>> Drop that
> 
> It would help for the sake of the uninitiated if you specified what to drop, 
> since your mail client has wrapped the quoted text incorrectly.
> 
>>> + +SRC_URI =
>>> "${SOURCEFORGE_MIRROR}/smartmontools/smartmontools-${PV}.tar.gz" +
>>> +inherit autotools diff --git
>>> a/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb
>>> b/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb new file
>>> mode 100644 index 0000000..93dc4db --- /dev/null +++
>>> b/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb @@ -0,0
>>> +1,5 @@ +require smartmontools.inc +PR = "${INC_PR}.1"
>>
>> And drop that.
>>
>> And do you really need a .inc?
> 
> Are we removing inc files if they were present in OE Classic? First I've heard 
> if we are...

If we are trying to reduce the number of versions of recipes we carry,
dropping .inc files would seem to be a good idea. I don't have strong
feelings, but it seems like something we should consider.

Philip
Paul Eggleton - April 27, 2013, 11:13 a.m.
On Saturday 27 April 2013 06:34:46 Philip Balister wrote:
> On 04/27/2013 04:24 AM, Paul Eggleton wrote:
> > On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
> >> And do you really need a .inc?
> > 
> > Are we removing inc files if they were present in OE Classic? First I've
> > heard if we are...
> 
> If we are trying to reduce the number of versions of recipes we carry,
> dropping .inc files would seem to be a good idea. I don't have strong
> feelings, but it seems like something we should consider.

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.

Cheers,
Paul
Nicolas Dechesne - April 29, 2013, 6:40 a.m.
On Sat, Apr 27, 2013 at 1:13 PM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
>> > On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
>> >> And do you really need a .inc?
>> >
>> > Are we removing inc files if they were present in OE Classic? First I've
>> > heard if we are...
>>
>> If we are trying to reduce the number of versions of recipes we carry,
>> dropping .inc files would seem to be a good idea. I don't have strong
>> feelings, but it seems like something we should consider.
>
> 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.

I put the .inc in this patch, indeed because it was there in OE
Classic. I can update the patch if there is a consensus to remove the
.inc.

also for the INC_PR, I added it, because I thought it makes sense for
.bb with .inc to have that. again, i can update the patch if you
recommend doing this way.

thx
Nicolas Dechesne - May 3, 2013, 2 p.m.
On Mon, Apr 29, 2013 at 8:40 AM, Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:
> On Sat, Apr 27, 2013 at 1:13 PM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
>>> > On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
>>> >> And do you really need a .inc?
>>> >
>>> > Are we removing inc files if they were present in OE Classic? First I've
>>> > heard if we are...
>>>
>>> If we are trying to reduce the number of versions of recipes we carry,
>>> dropping .inc files would seem to be a good idea. I don't have strong
>>> feelings, but it seems like something we should consider.
>>
>> 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.
>
> I put the .inc in this patch, indeed because it was there in OE
> Classic. I can update the patch if there is a consensus to remove the
> .inc.
>
> also for the INC_PR, I added it, because I thought it makes sense for
> .bb with .inc to have that. again, i can update the patch if you
> recommend doing this way.
>
> thx

hi, can you please let me know what I should do here? i can update the
patch if needed, but not sure there is a clear consensus on what to
do!

nicolas
Koen Kooi - May 3, 2013, 2:10 p.m.
Op 27 apr. 2013, om 13:13 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Saturday 27 April 2013 06:34:46 Philip Balister wrote:
>> On 04/27/2013 04:24 AM, Paul Eggleton wrote:
>>> On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
>>>> And do you really need a .inc?
>>> 
>>> Are we removing inc files if they were present in OE Classic? First I've
>>> heard if we are...
>> 
>> If we are trying to reduce the number of versions of recipes we carry,
>> dropping .inc files would seem to be a good idea. I don't have strong
>> feelings, but it seems like something we should consider.
> 
> 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?
Paul Eggleton - May 3, 2013, 2:30 p.m.
On Friday 03 May 2013 16:10:40 Koen Kooi wrote:
> Op 27 apr. 2013, om 13:13 heeft Paul Eggleton 
<paul.eggleton@linux.intel.com> het volgende geschreven:
> > On Saturday 27 April 2013 06:34:46 Philip Balister wrote:
> >> On 04/27/2013 04:24 AM, Paul Eggleton wrote:
> >>> On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
> >>>> And do you really need a .inc?
> >>> 
> >>> Are we removing inc files if they were present in OE Classic? First I've
> >>> heard if we are...
> >> 
> >> If we are trying to reduce the number of versions of recipes we carry,
> >> dropping .inc files would seem to be a good idea. I don't have strong
> >> feelings, but it seems like something we should consider.
> > 
> > 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?

Even assuming everyone who could possibly want this is reading this thread, 
which is unlikely, in the absence of time machines you won't hear from anyone 
who doesn't need it now but does in the future. 

As a general rule, people do often want to build versions of recipes from SCM 
repositories and having an inc file makes that a bit easier. If we already have 
the inc file split I can't see a compelling reason to drop it.

I would also point out that we were asked to preserve these in the original 
move to OE-Core and as far as I am aware we have done so.

Cheers,
Paul
Nicolas Dechesne - May 3, 2013, 2:30 p.m.
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. 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..

nicolas
Paul Eggleton - May 3, 2013, 2:35 p.m.
On Friday 03 May 2013 16:00:13 Nicolas Dechesne wrote:
> On Mon, Apr 29, 2013 at 8:40 AM, Nicolas Dechesne
> 
> <nicolas.dechesne@linaro.org> wrote:
> > On Sat, Apr 27, 2013 at 1:13 PM, Paul Eggleton
> > 
> > <paul.eggleton@linux.intel.com> wrote:
> >>> > On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
> >>> >> And do you really need a .inc?
> >>> > 
> >>> > Are we removing inc files if they were present in OE Classic? First
> >>> > I've
> >>> > heard if we are...
> >>> 
> >>> If we are trying to reduce the number of versions of recipes we carry,
> >>> dropping .inc files would seem to be a good idea. I don't have strong
> >>> feelings, but it seems like something we should consider.
> >> 
> >> 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.
> > 
> > I put the .inc in this patch, indeed because it was there in OE
> > Classic. I can update the patch if there is a consensus to remove the
> > .inc.
> > 
> > also for the INC_PR, I added it, because I thought it makes sense for
> > .bb with .inc to have that. again, i can update the patch if you
> > recommend doing this way.
> 
> hi, can you please let me know what I should do here? i can update the
> patch if needed, but not sure there is a clear consensus on what to
> do!

IMO, let's keep the separate inc file, but drop PR and INC_PR.

Cheers,
Paul
Koen Kooi - May 3, 2013, 2:39 p.m.
Op 3 mei 2013, om 16:30 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Friday 03 May 2013 16:10:40 Koen Kooi wrote:
>> Op 27 apr. 2013, om 13:13 heeft Paul Eggleton 
> <paul.eggleton@linux.intel.com> het volgende geschreven:
>>> On Saturday 27 April 2013 06:34:46 Philip Balister wrote:
>>>> On 04/27/2013 04:24 AM, Paul Eggleton wrote:
>>>>> On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
>>>>>> And do you really need a .inc?
>>>>> 
>>>>> Are we removing inc files if they were present in OE Classic? First I've
>>>>> heard if we are...
>>>> 
>>>> If we are trying to reduce the number of versions of recipes we carry,
>>>> dropping .inc files would seem to be a good idea. I don't have strong
>>>> feelings, but it seems like something we should consider.
>>> 
>>> 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?
> 
> Even assuming everyone who could possibly want this is reading this thread, 
> which is unlikely, in the absence of time machines you won't hear from anyone 
> who doesn't need it now but does in the future. 
> 
> As a general rule, people do often want to build versions of recipes from SCM 
> repositories and having an inc file makes that a bit easier. If we already have 
> the inc file split I can't see a compelling reason to drop it.
> 
> I would also point out that we were asked to preserve these in the original 
> move to OE-Core and as far as I am aware we have done so.

It's unnecessary clutter and in the smartmontools case unneeded as well.
Koen Kooi - May 3, 2013, 2:40 p.m.
Op 3 mei 2013, om 16:35 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Friday 03 May 2013 16:00:13 Nicolas Dechesne wrote:
>> On Mon, Apr 29, 2013 at 8:40 AM, Nicolas Dechesne
>> 
>> <nicolas.dechesne@linaro.org> wrote:
>>> On Sat, Apr 27, 2013 at 1:13 PM, Paul Eggleton
>>> 
>>> <paul.eggleton@linux.intel.com> wrote:
>>>>>> On Friday 26 April 2013 23:41:38 Koen Kooi wrote:
>>>>>>> And do you really need a .inc?
>>>>>> 
>>>>>> Are we removing inc files if they were present in OE Classic? First
>>>>>> I've
>>>>>> heard if we are...
>>>>> 
>>>>> If we are trying to reduce the number of versions of recipes we carry,
>>>>> dropping .inc files would seem to be a good idea. I don't have strong
>>>>> feelings, but it seems like something we should consider.
>>>> 
>>>> 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.
>>> 
>>> I put the .inc in this patch, indeed because it was there in OE
>>> Classic. I can update the patch if there is a consensus to remove the
>>> .inc.
>>> 
>>> also for the INC_PR, I added it, because I thought it makes sense for
>>> .bb with .inc to have that. again, i can update the patch if you
>>> recommend doing this way.
>> 
>> hi, can you please let me know what I should do here? i can update the
>> patch if needed, but not sure there is a clear consensus on what to
>> do!
> 
> IMO, let's keep the separate inc file, but drop PR and INC_PR.

I still haven't heard a compelling case why smartmontools needs a .inc and all the other recipes in meta-oe don't. So drop the inc and be consistent with other recipes.
Paul Eggleton - May 3, 2013, 2:42 p.m.
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.

> 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 - May 3, 2013, 2:48 p.m.
On Friday 03 May 2013 16:40:13 Koen Kooi wrote:
> Op 3 mei 2013, om 16:35 heeft Paul Eggleton <paul.eggleton@linux.intel.com>
> het volgende geschreven:
> > IMO, let's keep the separate inc file, but drop PR and INC_PR.
> 
> I still haven't heard a compelling case why smartmontools needs a .inc and
> all the other recipes in meta-oe don't. So drop the inc and be consistent
> with other recipes.

All the other recipes? You mean all of them except for the significant number 
you can find if you run "git grep require.*inc" in meta-oe?

On Friday 03 May 2013 16:39:13 Koen Kooi wrote:
> It's unnecessary clutter and in the smartmontools case unneeded as well.

How is it any less necessary for smartmontools than any other recipe?

Cheers,
Paul
Martin Jansa - May 3, 2013, 3:09 p.m.
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.

> > 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
Philip Balister - May 3, 2013, 3:15 p.m.
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
>
Nicolas Dechesne - May 6, 2013, 8:19 a.m.
On Fri, May 3, 2013 at 5:15 PM, Philip Balister <philip@balister.org> wrote:

> > 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.
>

ok ,thanks for all the inputs. I will rework the recipe, and remove the
.inc as more people seem to be willing it this way.

also, i realized that there is newer upstream version of smartmontools, so
i will upgrade the recipe to the most recent one too.

Patch

diff --git a/meta-oe/recipes-support/smartmontools/smartmontools.inc b/meta-oe/recipes-support/smartmontools/smartmontools.inc
new file mode 100644
index 0000000..6f23055
--- /dev/null
+++ b/meta-oe/recipes-support/smartmontools/smartmontools.inc
@@ -0,0 +1,10 @@ 
+SECTION = "console/utils"
+DESCRIPTION = "Control and monitor storage systems using S.M.A.R.T."
+HOMEPAGE = "http://smartmontools.sourceforge.net/"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
+INC_PR = "r1"
+
+SRC_URI = "${SOURCEFORGE_MIRROR}/smartmontools/smartmontools-${PV}.tar.gz"
+
+inherit autotools
diff --git a/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb b/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb
new file mode 100644
index 0000000..93dc4db
--- /dev/null
+++ b/meta-oe/recipes-support/smartmontools/smartmontools_5.40.bb
@@ -0,0 +1,5 @@ 
+require smartmontools.inc
+PR = "${INC_PR}.1"
+
+SRC_URI[md5sum] = "0f0be0239914ad87830a4fff594bda5b"
+SRC_URI[sha256sum] = "2a68ed20d5d6bd198e1aa6bf0b6037f0f216e3b14da022115244f1af9d248bfd"