Patchwork [CONSOLIDATED,PULL,(V2),00/35] Updates, Multilib Patches and other fixes

login
register
mail settings
Submitter Saul Wold
Date Jan. 5, 2013, 6:22 a.m.
Message ID <cover.1357366840.git.sgw@linux.intel.com>
Download mbox
Permalink /patch/42015/
State New
Headers show

Pull-request

git://git.openembedded.org/openembedded-core-contrib sgw/stage

Comments

Saul Wold - Jan. 5, 2013, 6:22 a.m.
Richard,

Finally another collected set of patches, my network access
was worse than I thought it would be the last few days.

I built these locally.

Thanks
	Sau!

The following changes since commit b693f6d3d48b281fbbf71fd56996c85e23c3a9c9:

  freetype: update to 2.4.11 which includes fixes for CVE-2012-{5668, 5669, 5670} (2012-12-31 09:42:49 +0000)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib sgw/stage
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage

Chen Qi (1):
  init-live.sh: avoid duplicate mount points for the same filesystem

Christopher Larson (6):
  update-alternatives.bbclass: use absolute paths for link targets
  opkg-native: obey virtual/update-alternatives-native
  chkconfig: don't inherit autotools
  chkconfig: obey sysconfdir, base_libdir
  chkconfig: package the update-alternatives implementation
  chkconfig-alternatives-native-1.3.59: add recipe

Constantin Musca (8):
  libpam: enable multilib
  package.bbclass: don't prepend MLPREFIX to LOCALEBASEPN
  eglibc-locale: enable multilib
  sysstat: fix sa_lib_dir
  rpm: replace /usr/lib with ${libdir}
  libfm: upgrade to 1.1.0
  pcmanfm: upgrade to 1.1.0
  vte: add missing unpackaged files

David Nyström (1):
  Added ability to parse python sources to create-recipe

Kang Kai (4):
  autoconf: update RDEDENDS
  perl: add sub-package perl-tests
  perl: update RPROVIDES and popuate_package script
  perl: update dependency creating script

Laurentiu Palcu (1):
  pango: have postinstalls run at do_rootfs time

Marko Lindqvist (7):
  automake: update to upstream version 1.12.6
  gmp: update SRC_URI and HOMEPAGE
  gmp: update to upstream version 5.1.0
  mpfr: update to upstream version 3.1.1
  icu: update to upstream version 50.1.1
  harfbuzz: add recipe, version 0.9.9
  pango: update to upstream version 1.32.5

Martin Jansa (1):
  kernel.bbclass: include PE in KERNEL_IMAGE_BASE_NAME

Noor Ahsan (1):
  cairo: Adds libxext in X11DEPENDS.

Robert P. J. Day (2):
  lib_package.bbclass: Correct comment referring to bin directories.
  package.bbclass: Skip testing "packages" a second time.

Saul Wold (3):
  libnl: Update to 3.2.16
  glib-2.0: Update to 2.35.3
  glib-networking: Update to 2.35.1

 meta/classes/kernel.bbclass                        |    2 +-
 meta/classes/lib_package.bbclass                   |    2 +-
 meta/classes/package.bbclass                       |    4 +-
 meta/classes/update-alternatives.bbclass           |    2 +-
 meta/recipes-core/eglibc/eglibc-locale.inc         |    4 +-
 .../{glib-2.0_2.34.3.bb => glib-2.0_2.35.3.bb}     |    4 +-
 meta/recipes-core/glib-2.0/glib.inc                |    2 +-
 ...working_2.28.7.bb => glib-networking_2.35.1.bb} |   10 +-
 meta/recipes-core/initrdscripts/files/init-live.sh |    9 +-
 meta/recipes-devtools/autoconf/autoconf.inc        |    1 -
 meta/recipes-devtools/autoconf/autoconf_2.69.bb    |    2 +-
 ...-compile-compile-only-optimized-byte-code.patch |   28 +-
 .../automake/automake/python-libdir.patch          |   41 +-
 .../{automake_1.12.5.bb => automake_1.12.6.bb}     |    4 +-
 meta/recipes-devtools/opkg/opkg.inc                |   10 +-
 meta/recipes-devtools/perl/perl-5.14.2/config.sh   |   18 +-
 .../recipes-devtools/perl/perl-rdepends_5.14.2.inc | 2336 +++++++++++++++++++-
 meta/recipes-devtools/perl/perl-tests.inc          |   34 +
 meta/recipes-devtools/perl/perl_5.14.2.bb          |   12 +-
 meta/recipes-devtools/rpm/rpm_5.4.9.bb             |    4 +-
 .../chkconfig-alternatives-native_1.3.59.bb        |   43 +
 .../recipes-extended/chkconfig/chkconfig_1.3.58.bb |   48 +-
 meta/recipes-extended/pam/libpam_1.1.6.bb          |   15 +-
 meta/recipes-extended/sysstat/sysstat.inc          |    6 +-
 meta/recipes-graphics/cairo/cairo.inc              |    2 +-
 meta/recipes-graphics/cairo/cairo_1.12.8.bb        |    2 +-
 meta/recipes-graphics/harfbuzz/harfbuzz_0.9.9.bb   |   27 +
 .../pango/pango-1.30.1/multilib-fix-clean.patch    |   42 -
 .../pango/pango-1.32.5/multilib-fix-clean.patch    |   60 +
 .../{pango-1.30.1 => pango-1.32.5}/no-tests.patch  |    0
 meta/recipes-graphics/pango/pango.inc              |   30 +-
 .../pango/{pango_1.30.1.bb => pango_1.32.5.bb}     |    4 +-
 .../pcmanfm/files/owl-window-menu.patch            |   81 -
 .../files/pcmanfm_fix_for_automake_1.12.patch      |   35 -
 .../{pcmanfm_0.9.10.bb => pcmanfm_1.1.0.bb}        |   11 +-
 .../gmp/{gmp => gmp-4.2.1}/configure.patch         |    0
 meta/recipes-support/gmp/gmp-5.1.0/configure.patch |  210 ++
 meta/recipes-support/gmp/gmp.inc                   |    4 +-
 .../gmp/gmp/gmp_fix_for_automake-1.12.patch        |   48 -
 .../gmp/{gmp_5.0.5.bb => gmp_5.1.0.bb}             |    5 +-
 meta/recipes-support/icu/icu_50.1.1.bb             |   11 +
 meta/recipes-support/icu/icu_50.1.bb               |   11 -
 .../libfm/libfm-0.1.17/configure_fix.patch         |   19 -
 .../libfm-0.1.17/libfm_fix_for_automake-1.12.patch |   48 -
 .../libfm-1.1.0/fix-make-parallelism-issue.patch   |   31 +
 .../libfm/{libfm_0.1.17.bb => libfm_1.1.0.bb}      |    8 +-
 .../libnl/{libnl_3.2.14.bb => libnl_3.2.16.bb}     |    4 +-
 .../mpfr-3.1.0/mpfr_fix_for_automake-1.12.patch    |   35 -
 .../long-long-thumb.patch                          |    0
 .../mpfr/{mpfr_3.1.0.bb => mpfr_3.1.1.bb}          |    7 +-
 meta/recipes-support/vte/vte.inc                   |    4 +-
 scripts/create-recipe                              |   51 +-
 52 files changed, 2944 insertions(+), 487 deletions(-)
 rename meta/recipes-core/glib-2.0/{glib-2.0_2.34.3.bb => glib-2.0_2.35.3.bb} (92%)
 rename meta/recipes-core/glib-networking/{glib-networking_2.28.7.bb => glib-networking_2.35.1.bb} (70%)
 rename meta/recipes-devtools/automake/{automake_1.12.5.bb => automake_1.12.6.bb} (90%)
 create mode 100644 meta/recipes-devtools/perl/perl-tests.inc
 create mode 100644 meta/recipes-extended/chkconfig/chkconfig-alternatives-native_1.3.59.bb
 create mode 100644 meta/recipes-graphics/harfbuzz/harfbuzz_0.9.9.bb
 delete mode 100644 meta/recipes-graphics/pango/pango-1.30.1/multilib-fix-clean.patch
 create mode 100644 meta/recipes-graphics/pango/pango-1.32.5/multilib-fix-clean.patch
 rename meta/recipes-graphics/pango/{pango-1.30.1 => pango-1.32.5}/no-tests.patch (100%)
 rename meta/recipes-graphics/pango/{pango_1.30.1.bb => pango_1.32.5.bb} (59%)
 delete mode 100644 meta/recipes-sato/pcmanfm/files/owl-window-menu.patch
 delete mode 100644 meta/recipes-sato/pcmanfm/files/pcmanfm_fix_for_automake_1.12.patch
 rename meta/recipes-sato/pcmanfm/{pcmanfm_0.9.10.bb => pcmanfm_1.1.0.bb} (76%)
 rename meta/recipes-support/gmp/{gmp => gmp-4.2.1}/configure.patch (100%)
 create mode 100644 meta/recipes-support/gmp/gmp-5.1.0/configure.patch
 delete mode 100644 meta/recipes-support/gmp/gmp/gmp_fix_for_automake-1.12.patch
 rename meta/recipes-support/gmp/{gmp_5.0.5.bb => gmp_5.1.0.bb} (60%)
 create mode 100644 meta/recipes-support/icu/icu_50.1.1.bb
 delete mode 100644 meta/recipes-support/icu/icu_50.1.bb
 delete mode 100644 meta/recipes-support/libfm/libfm-0.1.17/configure_fix.patch
 delete mode 100644 meta/recipes-support/libfm/libfm-0.1.17/libfm_fix_for_automake-1.12.patch
 create mode 100644 meta/recipes-support/libfm/libfm-1.1.0/fix-make-parallelism-issue.patch
 rename meta/recipes-support/libfm/{libfm_0.1.17.bb => libfm_1.1.0.bb} (75%)
 rename meta/recipes-support/libnl/{libnl_3.2.14.bb => libnl_3.2.16.bb} (90%)
 delete mode 100644 meta/recipes-support/mpfr/mpfr-3.1.0/mpfr_fix_for_automake-1.12.patch
 rename meta/recipes-support/mpfr/{mpfr-3.1.0 => mpfr-3.1.1}/long-long-thumb.patch (100%)
 rename meta/recipes-support/mpfr/{mpfr_3.1.0.bb => mpfr_3.1.1.bb} (65%)
Marko Lindqvist - Jan. 5, 2013, 6:52 a.m.
On 5 January 2013 08:22, Saul Wold <sgw@linux.intel.com> wrote:
>
> Saul Wold (3):
>   glib-2.0: Update to 2.35.3

 Is there some specific need for bleeding edge (unstable development snapshot)?



 - ML
Marko Lindqvist - Jan. 5, 2013, 11:36 p.m.
On 5 January 2013 08:22, Saul Wold <sgw@linux.intel.com> wrote:
>   harfbuzz: add recipe, version 0.9.9
>   pango: update to upstream version 1.32.5

 Is it either all or none going forward with these consolidated pulls?
I'm about to submit V2 of HarfBuzz patch fixing build occasionally
being unusable for pango (namely I will add glib-2.0 to dependencies,
as without glib present harfbuzz configure disables parts needed by
pango). New version of pango depends on HarfBuzz so if current
harfbuzz patch is not going in, neither can pango update.


 - ML
Saul Wold - Jan. 6, 2013, 4:29 a.m.
On 01/04/2013 10:52 PM, Marko Lindqvist wrote:
> On 5 January 2013 08:22, Saul Wold <sgw@linux.intel.com> wrote:
>>
>> Saul Wold (3):
>>    glib-2.0: Update to 2.35.3
>
>   Is there some specific need for bleeding edge (unstable development snapshot)?
>
I was updating glib-networking and it required glib 2.35.3, I had not 
checked (my bad that it was unstable).  Even after a number of years, I 
loose track sometimes of what's stable vs unstable (odd vs .99 vs ??)

We can drop both the glib and glib-networking patches.


Sau!

>
>
>   - ML
>
Marko Lindqvist - Jan. 6, 2013, 8:28 p.m.
On 6 January 2013 06:29, Saul Wold <sgw@linux.intel.com> wrote:
> On 01/04/2013 10:52 PM, Marko Lindqvist wrote:
>>
>> On 5 January 2013 08:22, Saul Wold <sgw@linux.intel.com> wrote:
>>>
>>>
>>> Saul Wold (3):
>>>    glib-2.0: Update to 2.35.3
>>
>>
>>   Is there some specific need for bleeding edge (unstable development
>> snapshot)?
>>
> I was updating glib-networking and it required glib 2.35.3, I had not
> checked (my bad that it was unstable).  Even after a number of years, I
> loose track sometimes of what's stable vs unstable (odd vs .99 vs ??)

 With gnome way of releasing stable versions of something depending on
something that is not yet really released (has not stable release) it
can be even quite frustrating. So you already have patch for
glib-networking we can apply once glib is updated to 2.36.

 Another challenge for http://packages.yoctoproject.org/ ?


 - ML
Richard Purdie - Jan. 7, 2013, 11:10 a.m.
On Fri, 2013-01-04 at 22:22 -0800, Saul Wold wrote:
> Richard,
> 
> Finally another collected set of patches, my network access
> was worse than I thought it would be the last few days.
> 
> I built these locally.
> 
> Thanks
> 	Sau!
> 
> The following changes since commit b693f6d3d48b281fbbf71fd56996c85e23c3a9c9:
> 
>   freetype: update to 2.4.11 which includes fixes for CVE-2012-{5668, 5669, 5670} (2012-12-31 09:42:49 +0000)
> 
> are available in the git repository at:
> 
>   git://git.openembedded.org/openembedded-core-contrib sgw/stage
>   http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=sgw/stage
> 
> Chen Qi (1):
>   init-live.sh: avoid duplicate mount points for the same filesystem
> 
> Christopher Larson (6):
>   update-alternatives.bbclass: use absolute paths for link targets
>   opkg-native: obey virtual/update-alternatives-native
>   chkconfig: don't inherit autotools
>   chkconfig: obey sysconfdir, base_libdir
>   chkconfig: package the update-alternatives implementation
>   chkconfig-alternatives-native-1.3.59: add recipe
> 
> Constantin Musca (8):
>   libpam: enable multilib
>   package.bbclass: don't prepend MLPREFIX to LOCALEBASEPN
>   eglibc-locale: enable multilib
>   sysstat: fix sa_lib_dir
>   rpm: replace /usr/lib with ${libdir}
>   libfm: upgrade to 1.1.0
>   pcmanfm: upgrade to 1.1.0
>   vte: add missing unpackaged files
> 
> David Nyström (1):
>   Added ability to parse python sources to create-recipe
> 
> Kang Kai (4):
>   autoconf: update RDEDENDS
>   perl: add sub-package perl-tests
>   perl: update RPROVIDES and popuate_package script
>   perl: update dependency creating script
> 
> Laurentiu Palcu (1):
>   pango: have postinstalls run at do_rootfs time
> 
> Marko Lindqvist (7):
>   automake: update to upstream version 1.12.6
>   gmp: update SRC_URI and HOMEPAGE
>   gmp: update to upstream version 5.1.0
>   mpfr: update to upstream version 3.1.1
>   icu: update to upstream version 50.1.1
>   harfbuzz: add recipe, version 0.9.9
>   pango: update to upstream version 1.32.5
> 
> Martin Jansa (1):
>   kernel.bbclass: include PE in KERNEL_IMAGE_BASE_NAME
> 
> Noor Ahsan (1):
>   cairo: Adds libxext in X11DEPENDS.
> 
> Robert P. J. Day (2):
>   lib_package.bbclass: Correct comment referring to bin directories.
>   package.bbclass: Skip testing "packages" a second time.
> 
> Saul Wold (3):
>   libnl: Update to 3.2.16
>   glib-2.0: Update to 2.35.3
>   glib-networking: Update to 2.35.1

Merged, apart from harfbuzz, pango, glib and glib-networking changes as
per the feedback on list.

Cheers,

Richard
Laurentiu Palcu - Jan. 7, 2013, 12:31 p.m.
On 01/07/2013 01:10 PM, Richard Purdie wrote:
> On Fri, 2013-01-04 at 22:22 -0800, Saul Wold wrote:
>>
>> Laurentiu Palcu (1):
>>   pango: have postinstalls run at do_rootfs time
> 
> Merged, apart from harfbuzz, pango, glib and glib-networking changes as
> per the feedback on list.
I think pango can be merged. The comments on the list are about other
packages that ship pango modules, in which case the qemu approach should
be used.

Thanks,
Laurentiu
> 
> Cheers,
> 
> Richard
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Marko Lindqvist - Jan. 7, 2013, 12:38 p.m.
On 7 January 2013 14:31, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
>
>
> On 01/07/2013 01:10 PM, Richard Purdie wrote:
>> On Fri, 2013-01-04 at 22:22 -0800, Saul Wold wrote:
>>>
>>> Laurentiu Palcu (1):
>>>   pango: have postinstalls run at do_rootfs time
>>
>> Merged, apart from harfbuzz, pango, glib and glib-networking changes as
>> per the feedback on list.
> I think pango can be merged. The comments on the list are about other
> packages that ship pango modules, in which case the qemu approach should
> be used.

 This was about pango update (to 1.32) to depend on harfbuzz so when
harfbuzz was dropped, pango update had to be dropped too (it wouldn't
build)


 - ML
Laurentiu Palcu - Jan. 7, 2013, 12:41 p.m.
On 01/07/2013 02:38 PM, Marko Lindqvist wrote:
> On 7 January 2013 14:31, Laurentiu Palcu <laurentiu.palcu@intel.com> wrote:
>>
>>
>> On 01/07/2013 01:10 PM, Richard Purdie wrote:
>>> On Fri, 2013-01-04 at 22:22 -0800, Saul Wold wrote:
>>>>
>>>> Laurentiu Palcu (1):
>>>>   pango: have postinstalls run at do_rootfs time
>>>
>>> Merged, apart from harfbuzz, pango, glib and glib-networking changes as
>>> per the feedback on list.
>> I think pango can be merged. The comments on the list are about other
>> packages that ship pango modules, in which case the qemu approach should
>> be used.
> 
>  This was about pango update (to 1.32) to depend on harfbuzz so when
> harfbuzz was dropped, pango update had to be dropped too (it wouldn't
> build)
Sorry for the noise then. I missed the pango update commit line...

Thanks,
Laurentiu
> 
> 
>  - ML
>
Marko Lindqvist - Jan. 9, 2013, 7:46 a.m.
On 6 January 2013 22:28, Marko Lindqvist <cazfi74@gmail.com> wrote:
> On 6 January 2013 06:29, Saul Wold <sgw@linux.intel.com> wrote:
>>>
>> Even after a number of years, I
>> loose track sometimes of what's stable vs unstable (odd vs .99 vs ??)
>
>  Another challenge for http://packages.yoctoproject.org/ ?

 Actually, does it even know how new major versions will be in new
directory? Asking because I don't know even if it collects the URL to
check from recipes, or is that given in some specfile. At least gtk+3
recipe in meta-openembedded has that directory hardcoded
".../gtk+/3.4/gtk+-${PV}.tar.xz" so when ever updating to new major
version, SRC_URI needs to be touched.
 What I'm envisioning is that maybe bitbake should provide us with new
variable PM or PMV (major version) that's basically PV with last dot
and everything after it removed. That would allow us to easily make
many such SRC_URIs dynamic, e.g., ".../gtk+/${PM}/gtk+-${PV}.tar.xz".
This would be more worthsome if it's something
packages.yoctoproject.org too could benefit from.


 - ML
Martin Jansa - Jan. 9, 2013, 9:13 a.m.
On Wed, Jan 09, 2013 at 09:46:57AM +0200, Marko Lindqvist wrote:
> On 6 January 2013 22:28, Marko Lindqvist <cazfi74@gmail.com> wrote:
> > On 6 January 2013 06:29, Saul Wold <sgw@linux.intel.com> wrote:
> >>>
> >> Even after a number of years, I
> >> loose track sometimes of what's stable vs unstable (odd vs .99 vs ??)
> >
> >  Another challenge for http://packages.yoctoproject.org/ ?
> 
>  Actually, does it even know how new major versions will be in new
> directory? Asking because I don't know even if it collects the URL to
> check from recipes, or is that given in some specfile. At least gtk+3
> recipe in meta-openembedded has that directory hardcoded
> ".../gtk+/3.4/gtk+-${PV}.tar.xz" so when ever updating to new major
> version, SRC_URI needs to be touched.
>  What I'm envisioning is that maybe bitbake should provide us with new
> variable PM or PMV (major version) that's basically PV with last dot
> and everything after it removed. That would allow us to easily make
> many such SRC_URIs dynamic, e.g., ".../gtk+/${PM}/gtk+-${PV}.tar.xz".
> This would be more worthsome if it's something
> packages.yoctoproject.org too could benefit from.

That looks like SHRT_VER used in some recipes.

Cheers,
Marko Lindqvist - Jan. 9, 2013, 9:33 a.m.
On 9 January 2013 11:13, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Wed, Jan 09, 2013 at 09:46:57AM +0200, Marko Lindqvist wrote:
>>  What I'm envisioning is that maybe bitbake should provide us with new
>> variable PM or PMV (major version) that's basically PV with last dot
>> and everything after it removed. That would allow us to easily make
>> many such SRC_URIs dynamic, e.g., ".../gtk+/${PM}/gtk+-${PV}.tar.xz".
>> This would be more worthsome if it's something
>> packages.yoctoproject.org too could benefit from.
>
> That looks like SHRT_VER used in some recipes.

 Exactly, except that it would be provided by bitbake, and not
constructed by each recipe itself - less recipe writing work + you
could count on it to always mean same thing.


 - ML
Ross Burton - Jan. 9, 2013, 9:42 a.m.
On Wednesday, 9 January 2013 at 09:33, Marko Lindqvist wrote:
> Exactly, except that it would be provided by bitbake, and not
> constructed by each recipe itself - less recipe writing work + you
> could count on it to always mean same thing.

Everything but the last dot, or the first two components, or what?  For anything GNOMEy you want the first two elements as some packages use nano releases for development snapshots (1.2.3.4).

Ross
Marko Lindqvist - Jan. 9, 2013, 10 a.m.
On 9 January 2013 11:42, Ross Burton <ross.burton@intel.com> wrote:
> On Wednesday, 9 January 2013 at 09:33, Marko Lindqvist wrote:
>> Exactly, except that it would be provided by bitbake, and not
>> constructed by each recipe itself - less recipe writing work + you
>> could count on it to always mean same thing.
>
> Everything but the last dot, or the first two components, or what?  For anything GNOMEy you want the first two elements as some packages use nano releases for development snapshots (1.2.3.4).

 Ok, do we have any counter-examples where you'd want, say, three out
of four parts? One out of n? Of course there will always be need to
use variables of their own in some recipes, but I'm after something
that would be usable in most cases.


 - ML
Martin Jansa - Jan. 9, 2013, 10:29 a.m.
On Wed, Jan 09, 2013 at 12:00:20PM +0200, Marko Lindqvist wrote:
> On 9 January 2013 11:42, Ross Burton <ross.burton@intel.com> wrote:
> > On Wednesday, 9 January 2013 at 09:33, Marko Lindqvist wrote:
> >> Exactly, except that it would be provided by bitbake, and not
> >> constructed by each recipe itself - less recipe writing work + you
> >> could count on it to always mean same thing.
> >
> > Everything but the last dot, or the first two components, or what?  For anything GNOMEy you want the first two elements as some packages use nano releases for development snapshots (1.2.3.4).
> 
>  Ok, do we have any counter-examples where you'd want, say, three out
> of four parts? One out of n? Of course there will always be need to
> use variables of their own in some recipes, but I'm after something
> that would be usable in most cases.

I don't remember where but 1st of 4 is also used. 
What about stuff like "1.2.3.4+gitAUTOINC"?

GNOME is quite consistent, but it still looks better defined in
recipe/bbclass then having "something" defined by bitbake in all recipes
and usable only in some.
Marko Lindqvist - Jan. 9, 2013, 10:42 a.m.
On 9 January 2013 12:29, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Wed, Jan 09, 2013 at 12:00:20PM +0200, Marko Lindqvist wrote:
>> On 9 January 2013 11:42, Ross Burton <ross.burton@intel.com> wrote:
>> > On Wednesday, 9 January 2013 at 09:33, Marko Lindqvist wrote:
>> >> Exactly, except that it would be provided by bitbake, and not
>> >> constructed by each recipe itself - less recipe writing work + you
>> >> could count on it to always mean same thing.
>> >
>> > Everything but the last dot, or the first two components, or what?  For anything GNOMEy you want the first two elements as some packages use nano releases for development snapshots (1.2.3.4).
>>
>>  Ok, do we have any counter-examples where you'd want, say, three out
>> of four parts? One out of n? Of course there will always be need to
>> use variables of their own in some recipes, but I'm after something
>> that would be usable in most cases.
>
> I don't remember where but 1st of 4 is also used.
> What about stuff like "1.2.3.4+gitAUTOINC"?
>
> GNOME is quite consistent, but it still looks better defined in
> recipe/bbclass then having "something" defined by bitbake in all recipes
> and usable only in some.

 Given the examples, yes. Only if external tools would benefit (=
could use bitbake defined, but not recipe constructed var), defining
it bitbake side would make sense.


 - ML