Patchwork [3/4] tar: upgrade to v1.26

Signed-off-by: Scott Garman <scott.a.garman@intel.com>
---
 ...tive_1.25.bb => tar-replacement-native_1.26.bb} |    0
 meta/recipes-extended/tar/tar.inc                  |    1 +
 meta/recipes-extended/tar/tar_1.25.bb              |    9 ---------
 meta/recipes-extended/tar/tar_1.26.bb              |    9 +++++++++
 4 files changed, 10 insertions(+), 9 deletions(-)
 rename meta/recipes-extended/tar/{tar-replacement-native_1.25.bb => tar-replacement-native_1.26.bb} (100%)
 delete mode 100644 meta/recipes-extended/tar/tar_1.25.bb
 create mode 100644 meta/recipes-extended/tar/tar_1.26.bb

On Sun, 2011-06-05 at 21:49 -0700, Scott Garman wrote:
>  SECTION = "base"
> +PRIORITY = "optional"

Seeing this sort of thing makes me wonder whether SECTION and PRIORITY
actually belong in the core metadata at all.  It seems as though the
determination of what exactly is "standard" vs "optional" is a matter of
distro policy and this would be better done in the distro config files.

Also, just on a pragmatic issue, the two values above are actually what
bitbake.conf sets as default anyway so there isn't much to be gained by
specifying them in the recipe as well.

p.

On Mon, 2011-06-06 at 09:00 +0100, Phil Blundell wrote:
> On Sun, 2011-06-05 at 21:49 -0700, Scott Garman wrote:
> >  SECTION = "base"
> > +PRIORITY = "optional"
> 
> Seeing this sort of thing makes me wonder whether SECTION and PRIORITY
> actually belong in the core metadata at all.  It seems as though the
> determination of what exactly is "standard" vs "optional" is a matter of
> distro policy and this would be better done in the distro config files.
> 
> Also, just on a pragmatic issue, the two values above are actually what
> bitbake.conf sets as default anyway so there isn't much to be gained by
> specifying them in the recipe as well.

I have to admit I keep wondering about these.

PRIORITY does seem a bit of a pointless variable in the default metadata
and I'm borderline in favour of dropping it and leaving it to any
distros who want to use it, maybe sharing an include file.

SECTION does at least start to become useful in an image generation UI
as a way to group packages roughly by type which makes me think it has a
good default usecase (and OE-Core did clean up the values of it to at
least be consistent).

Cheers,

Richard

On 6/6/11 5:46 AM, Richard Purdie wrote:
> On Mon, 2011-06-06 at 09:00 +0100, Phil Blundell wrote:
>> On Sun, 2011-06-05 at 21:49 -0700, Scott Garman wrote:
>>>  SECTION = "base"
>>> +PRIORITY = "optional"
>>
>> Seeing this sort of thing makes me wonder whether SECTION and PRIORITY
>> actually belong in the core metadata at all.  It seems as though the
>> determination of what exactly is "standard" vs "optional" is a matter of
>> distro policy and this would be better done in the distro config files.
>>
>> Also, just on a pragmatic issue, the two values above are actually what
>> bitbake.conf sets as default anyway so there isn't much to be gained by
>> specifying them in the recipe as well.
> 
> I have to admit I keep wondering about these.
> 
> PRIORITY does seem a bit of a pointless variable in the default metadata
> and I'm borderline in favour of dropping it and leaving it to any
> distros who want to use it, maybe sharing an include file.

I agree as well, PRIORITY seems a bit iffy at this point.

> SECTION does at least start to become useful in an image generation UI
> as a way to group packages roughly by type which makes me think it has a
> good default usecase (and OE-Core did clean up the values of it to at
> least be consistent).

I think the value of SECTION needs to remain.  It's being used to group the
packages (as Richard mentions...)

Just my 2-cents.

--Mark

> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

On Mon, 2011-06-06 at 07:09 -0500, Mark Hatle wrote:
> On 6/6/11 5:46 AM, Richard Purdie wrote:
> > PRIORITY does seem a bit of a pointless variable in the default metadata
> > and I'm borderline in favour of dropping it and leaving it to any
> > distros who want to use it, maybe sharing an include file.
> 
> I agree as well, PRIORITY seems a bit iffy at this point.

So do we have a consensus that PRIORITY should be removed?  Is there
anybody who wants to speak up in favour of keeping it?

> > SECTION does at least start to become useful in an image generation UI
> > as a way to group packages roughly by type which makes me think it has a
> > good default usecase (and OE-Core did clean up the values of it to at
> > least be consistent).
> 
> I think the value of SECTION needs to remain.  It's being used to group the
> packages (as Richard mentions...)

Yeah, fair enough.  SECTION does appear in output packages (at least for
ipk/deb, it's mapped to the Section: header), but there is probably no
harm in having it used for source package grouping in oecommander-type
interfaces as well.  And I guess, unlike PRIORITY, it does seem
reasonable for the core metadata to assign some half-sensible default
package sections as a starting point for distro customisation.

p.