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

Submitted by Scott Garman on June 6, 2011, 4:49 a.m.

Details

Message ID 300cfa12d67e37c81fbbcdaba5c7d7686a191cfe.1307331820.git.scott.a.garman@intel.com
State New, archived
Headers show

Commit Message

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

Patch hide | download patch | download mbox

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"

Comments

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.