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

login
register
mail settings
Submitter Scott Garman
Date June 6, 2011, 4:49 a.m.
Message ID <300cfa12d67e37c81fbbcdaba5c7d7686a191cfe.1307331820.git.scott.a.garman@intel.com>
Download mbox | patch
Permalink /patch/5399/
State New, archived
Headers show

Comments

Scott Garman - June 6, 2011, 4:49 a.m.
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
Phil Blundell - June 6, 2011, 8 a.m.
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.
Richard Purdie - June 6, 2011, 10:46 a.m.
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
Mark Hatle - June 6, 2011, 12:09 p.m.
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
Phil Blundell - June 7, 2011, 8:24 a.m.
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.

Patch

diff --git a/meta/recipes-extended/tar/tar-replacement-native_1.25.bb b/meta/recipes-extended/tar/tar-replacement-native_1.26.bb
similarity index 100%
rename from meta/recipes-extended/tar/tar-replacement-native_1.25.bb
rename to meta/recipes-extended/tar/tar-replacement-native_1.26.bb
diff --git a/meta/recipes-extended/tar/tar.inc b/meta/recipes-extended/tar/tar.inc
index 6e77051..bbed65c 100644
--- a/meta/recipes-extended/tar/tar.inc
+++ b/meta/recipes-extended/tar/tar.inc
@@ -3,6 +3,7 @@  DESCRIPTION = "GNU tar saves many files together into a single tape \
 or disk archive, and can restore individual files from the archive."
 HOMEPAGE = "http://www.gnu.org/software/tar/"
 SECTION = "base"
+PRIORITY = "optional"
 
 SRC_URI = "${GNU_MIRROR}/tar/tar-${PV}.tar.bz2"
 
diff --git a/meta/recipes-extended/tar/tar_1.25.bb b/meta/recipes-extended/tar/tar_1.25.bb
deleted file mode 100644
index cdb6f54..0000000
--- a/meta/recipes-extended/tar/tar_1.25.bb
+++ /dev/null
@@ -1,9 +0,0 @@ 
-require tar.inc
-
-LICENSE = "GPLv3"
-LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
-
-PR = "r0"
-
-SRC_URI[md5sum] = "6e497f861c77bbba2f7da4e10270995b"
-SRC_URI[sha256sum] = "f3f6ce41b8e0f327abd05c95990f113ddafbae131e10f79a99728ed46458494b"
diff --git a/meta/recipes-extended/tar/tar_1.26.bb b/meta/recipes-extended/tar/tar_1.26.bb
new file mode 100644
index 0000000..26fdc4a
--- /dev/null
+++ b/meta/recipes-extended/tar/tar_1.26.bb
@@ -0,0 +1,9 @@ 
+require tar.inc
+
+LICENSE = "GPLv3"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
+
+PR = "r0"
+
+SRC_URI[md5sum] = "2cee42a2ff4f1cd4f9298eeeb2264519"
+SRC_URI[sha256sum] = "5a5369f464502a598e938029c310d4b3abd51e6bb8dfd045663e61c8ea9f6d41"