[RFC} glib-2.0 cleanup

[RFC} glib-2.0 cleanup

[Frans Meulenbroeks]

We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
Only a few versions are used (see also the grep below)

for glib-2.0:
"2.12.12"
"2.16.4"
"2.18.3"
"2.20.3"
"2.22.1"
"2.22.4"
"2.6.4"
"2.8.6"

for glib-2.0-native:
"2.16.1"
"2.18.0"
"2.22.1"
"2.22.4"

Both include the last two versions
Proposal is to remove all versions that are not used.

How do people feel about this?

Frans


 frans@linux-suse:~/oe/openembedded/recipes/glib-2.0> ls
bug-556515.patch  glib-2.0-2.16.3         glib-2.0-native_2.12.4.bb
glib-2.0_2.12.13.bb  glib-2.0_2.18.1.bb
files             glib-2.0-2.16.4         glib-2.0-native_2.16.1.bb
glib-2.0_2.12.6.bb   glib-2.0_2.18.3.bb
glib-2.0-2.12.10  glib-2.0-2.16.5         glib-2.0-native_2.18.0.bb
glib-2.0_2.12.9.bb   glib-2.0_2.2.3.bb
glib-2.0-2.12.11  glib-2.0-2.18.0         glib-2.0-native_2.2.3.bb
glib-2.0_2.14.0.bb   glib-2.0_2.20.3.bb
glib-2.0-2.12.12  glib-2.0-2.18.1         glib-2.0-native_2.22.1.bb
glib-2.0_2.14.1.bb   glib-2.0_2.20.4.bb
glib-2.0-2.12.13  glib-2.0-2.18.3         glib-2.0-native_2.4.6.bb
glib-2.0_2.14.4.bb   glib-2.0_2.22.1.bb
glib-2.0-2.12.9   glib-2.0-2.2.3          glib-2.0-native_2.6.5.bb
glib-2.0_2.15.6.bb   glib-2.0_2.22.4.bb
glib-2.0-2.14.0   glib-2.0-2.20.3         glib-2.0-native_2.6.6.bb
glib-2.0_2.16.1.bb   glib-2.0_2.4.6.bb
glib-2.0-2.14.1   glib-2.0-2.20.4         glib-2.0.inc
glib-2.0_2.16.3.bb   glib-2.0_2.6.4.bb
glib-2.0-2.14.4   glib-2.0-2.22.1         glib-2.0_2.12.10.bb
glib-2.0_2.16.4.bb   glib-2.0_2.6.6.bb
glib-2.0-2.15.6   glib-2.0-2.22.4         glib-2.0_2.12.11.bb
glib-2.0_2.16.5.bb   glib-2.0_2.8.6.bb
glib-2.0-2.16.1   glib-2.0-native-2.12.4  glib-2.0_2.12.12.bb
glib-2.0_2.18.0.bb   glib.inc
frans@linux-suse:~/oe/openembedded/recipes/glib-2.0> grep PREFERENCE *
glib-2.0_2.16.3.bb:DEFAULT_PREFERENCE = "-1"
glib-2.0_2.16.4.bb:DEFAULT_PREFERENCE = "-1"
glib-2.0_2.16.5.bb:DEFAULT_PREFERENCE = "-1"
frans@linux-suse:~/oe/openembedded/recipes/glib-2.0> grep -r glib-2.0 ../../conf
../../conf/distro/micro.conf:USE_NLS_glib-2.0 = "yes"
../../conf/distro/micro.conf:USE_NLS_glib-2.0-native = "yes"
../../conf/distro/chinook-compat.conf:PREFERRED_VERSION_glib-2.0
  = "2.12.12"
../../conf/distro/chinook-compat.conf:PKG_glib-2.0 = "libglib2.0-0"
../../conf/distro/maemo5-compat.conf:PREFERRED_VERSION_glib-2.0
 = "2.20.3"
../../conf/distro/maemo5-compat.conf:PKG_glib-2.0 = "libglib2.0-0"
../../conf/distro/include/angstrom-2008-preferred-versions.inc:PREFERRED_VERSION_glib-2.0
	= "2.22.4"
../../conf/distro/include/angstrom-2008-preferred-versions.inc:PREFERRED_VERSION_glib-2.0-native
= "2.22.4"
../../conf/distro/include/kaeilos-2009-preferred-versions.inc:PREFERRED_VERSION_glib-2.0
	= "2.22.4"
../../conf/distro/include/kaeilos-2009-preferred-versions.inc:PREFERRED_VERSION_glib-2.0-native
= "2.22.4"
../../conf/distro/include/preferred-gpe-versions-2.7.inc:PREFERRED_VERSION_glib-2.0
?= "2.6.4"
../../conf/distro/include/angstrom-uclibc.inc:USE_NLS_glib-2.0 = "yes"
../../conf/distro/include/angstrom-uclibc.inc:USE_NLS_glib-2.0-native = "yes"
../../conf/distro/include/sane-toolchain-uclinux-uclibc.inc:USE_NLS_glib-2.0
= "yes"
../../conf/distro/include/sane-toolchain-uclinux-uclibc.inc:USE_NLS_glib-2.0-native
= "yes"
../../conf/distro/include/preferred-om-2008-versions.inc:PREFERRED_VERSION_glib-2.0
?= "2.16.4"
../../conf/distro/include/preferred-om-2008-versions.inc:PREFERRED_VERSION_glib-2.0-native
?= "2.16.1"
../../conf/distro/include/slugos.inc:# glib-2.0 builds require USE_NLS
to be overridden
../../conf/distro/include/slugos.inc:USE_NLS_glib-2.0 = "yes"
../../conf/distro/include/slugos.inc:USE_NLS_glib-2.0-native = "yes"
../../conf/distro/include/preferred-shr-versions.inc:PREFERRED_VERSION_glib-2.0
     = "2.22.4"
../../conf/distro/include/preferred-shr-versions.inc:PREFERRED_VERSION_glib-2.0-native
= "2.22.4"
../../conf/distro/include/preferred-slugos-versions.inc:PREFERRED_VERSION_glib-2.0			?=
"2.22.1"
../../conf/distro/include/preferred-slugos-versions.inc:PREFERRED_VERSION_glib-2.0-native		?=
"2.22.1"
../../conf/distro/include/preferred-om-2009-versions.inc:PREFERRED_VERSION_glib-2.0
     = "2.18.3"
../../conf/distro/include/preferred-om-2009-versions.inc:PREFERRED_VERSION_glib-2.0-native
= "2.18.0"
../../conf/distro/include/angstrom-uclinux-uclibc.inc:USE_NLS_glib-2.0 = "yes"
../../conf/distro/include/angstrom-uclinux-uclibc.inc:USE_NLS_glib-2.0-native
= "yes"
../../conf/distro/include/maemo-preferred.inc:PREFERRED_VERSION_glib-2.0
= "2.6.4"
../../conf/distro/include/preferred-gpe-versions-2.8.inc:PREFERRED_VERSION_glib-2.0
?= "2.8.6"
../../conf/distro/include/sane-toolchain-uclibc.inc:USE_NLS_glib-2.0 = "yes"
../../conf/distro/include/sane-toolchain-uclibc.inc:USE_NLS_glib-2.0-native
= "yes"

Re: [RFC} glib-2.0 cleanup

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How do you know that some versions aren't used at all? Did you check all
external overlays?

But more importantly, what harm do the recipes do to you? Does it offend
you that there are 26 recipes?

What are you trying to accomplish?

If a recipe isn't doing any harm, just leave it alone. Deleting recipes
just to please someones sense of aesthetics is the wrong thing to do.

What would be a lot better is to fix the latest version for each minor
release to use things like new style staging, bbclassextend, etc and
*after* that clean up ask to remove the recipes that weren't updated.
That way there is a recipe for each minor version so we can check
regressions quite easily. But the real bonus is that the remaining
recipes are of good quality. Your proposal doesn't address any QA
concerns, it just makes the mess a bit smaller.

And even then I would rather move recipe + associated patches to
obsolete than delete it. When we start doing tarball releases
recipes/obsolete will be a lot more important than it is now.

On 28-02-10 20:39, Frans Meulenbroeks wrote:
> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
> Only a few versions are used (see also the grep below)
> 
> for glib-2.0:
> "2.12.12"
> "2.16.4"
> "2.18.3"
> "2.20.3"
> "2.22.1"
> "2.22.4"
> "2.6.4"
> "2.8.6"
> 
> for glib-2.0-native:
> "2.16.1"
> "2.18.0"
> "2.22.1"
> "2.22.4"
> 
> Both include the last two versions
> Proposal is to remove all versions that are not used.
> 
> How do people feel about this?
> 
> Frans
> 
> 
>  frans@linux-suse:~/oe/openembedded/recipes/glib-2.0> ls
> bug-556515.patch  glib-2.0-2.16.3         glib-2.0-native_2.12.4.bb
> glib-2.0_2.12.13.bb  glib-2.0_2.18.1.bb
> files             glib-2.0-2.16.4         glib-2.0-native_2.16.1.bb
> glib-2.0_2.12.6.bb   glib-2.0_2.18.3.bb
> glib-2.0-2.12.10  glib-2.0-2.16.5         glib-2.0-native_2.18.0.bb
> glib-2.0_2.12.9.bb   glib-2.0_2.2.3.bb
> glib-2.0-2.12.11  glib-2.0-2.18.0         glib-2.0-native_2.2.3.bb
> glib-2.0_2.14.0.bb   glib-2.0_2.20.3.bb
> glib-2.0-2.12.12  glib-2.0-2.18.1         glib-2.0-native_2.22.1.bb
> glib-2.0_2.14.1.bb   glib-2.0_2.20.4.bb
> glib-2.0-2.12.13  glib-2.0-2.18.3         glib-2.0-native_2.4.6.bb
> glib-2.0_2.14.4.bb   glib-2.0_2.22.1.bb
> glib-2.0-2.12.9   glib-2.0-2.2.3          glib-2.0-native_2.6.5.bb
> glib-2.0_2.15.6.bb   glib-2.0_2.22.4.bb
> glib-2.0-2.14.0   glib-2.0-2.20.3         glib-2.0-native_2.6.6.bb
> glib-2.0_2.16.1.bb   glib-2.0_2.4.6.bb
> glib-2.0-2.14.1   glib-2.0-2.20.4         glib-2.0.inc
> glib-2.0_2.16.3.bb   glib-2.0_2.6.4.bb
> glib-2.0-2.14.4   glib-2.0-2.22.1         glib-2.0_2.12.10.bb
> glib-2.0_2.16.4.bb   glib-2.0_2.6.6.bb
> glib-2.0-2.15.6   glib-2.0-2.22.4         glib-2.0_2.12.11.bb
> glib-2.0_2.16.5.bb   glib-2.0_2.8.6.bb
> glib-2.0-2.16.1   glib-2.0-native-2.12.4  glib-2.0_2.12.12.bb
> glib-2.0_2.18.0.bb   glib.inc
> frans@linux-suse:~/oe/openembedded/recipes/glib-2.0> grep PREFERENCE *
> glib-2.0_2.16.3.bb:DEFAULT_PREFERENCE = "-1"
> glib-2.0_2.16.4.bb:DEFAULT_PREFERENCE = "-1"
> glib-2.0_2.16.5.bb:DEFAULT_PREFERENCE = "-1"
> frans@linux-suse:~/oe/openembedded/recipes/glib-2.0> grep -r glib-2.0 ../../conf
> ../../conf/distro/micro.conf:USE_NLS_glib-2.0 = "yes"
> ../../conf/distro/micro.conf:USE_NLS_glib-2.0-native = "yes"
> ../../conf/distro/chinook-compat.conf:PREFERRED_VERSION_glib-2.0
>   = "2.12.12"
> ../../conf/distro/chinook-compat.conf:PKG_glib-2.0 = "libglib2.0-0"
> ../../conf/distro/maemo5-compat.conf:PREFERRED_VERSION_glib-2.0
>  = "2.20.3"
> ../../conf/distro/maemo5-compat.conf:PKG_glib-2.0 = "libglib2.0-0"
> ../../conf/distro/include/angstrom-2008-preferred-versions.inc:PREFERRED_VERSION_glib-2.0
> 	= "2.22.4"
> ../../conf/distro/include/angstrom-2008-preferred-versions.inc:PREFERRED_VERSION_glib-2.0-native
> = "2.22.4"
> ../../conf/distro/include/kaeilos-2009-preferred-versions.inc:PREFERRED_VERSION_glib-2.0
> 	= "2.22.4"
> ../../conf/distro/include/kaeilos-2009-preferred-versions.inc:PREFERRED_VERSION_glib-2.0-native
> = "2.22.4"
> ../../conf/distro/include/preferred-gpe-versions-2.7.inc:PREFERRED_VERSION_glib-2.0
> ?= "2.6.4"
> ../../conf/distro/include/angstrom-uclibc.inc:USE_NLS_glib-2.0 = "yes"
> ../../conf/distro/include/angstrom-uclibc.inc:USE_NLS_glib-2.0-native = "yes"
> ../../conf/distro/include/sane-toolchain-uclinux-uclibc.inc:USE_NLS_glib-2.0
> = "yes"
> ../../conf/distro/include/sane-toolchain-uclinux-uclibc.inc:USE_NLS_glib-2.0-native
> = "yes"
> ../../conf/distro/include/preferred-om-2008-versions.inc:PREFERRED_VERSION_glib-2.0
> ?= "2.16.4"
> ../../conf/distro/include/preferred-om-2008-versions.inc:PREFERRED_VERSION_glib-2.0-native
> ?= "2.16.1"
> ../../conf/distro/include/slugos.inc:# glib-2.0 builds require USE_NLS
> to be overridden
> ../../conf/distro/include/slugos.inc:USE_NLS_glib-2.0 = "yes"
> ../../conf/distro/include/slugos.inc:USE_NLS_glib-2.0-native = "yes"
> ../../conf/distro/include/preferred-shr-versions.inc:PREFERRED_VERSION_glib-2.0
>      = "2.22.4"
> ../../conf/distro/include/preferred-shr-versions.inc:PREFERRED_VERSION_glib-2.0-native
> = "2.22.4"
> ../../conf/distro/include/preferred-slugos-versions.inc:PREFERRED_VERSION_glib-2.0			?=
> "2.22.1"
> ../../conf/distro/include/preferred-slugos-versions.inc:PREFERRED_VERSION_glib-2.0-native		?=
> "2.22.1"
> ../../conf/distro/include/preferred-om-2009-versions.inc:PREFERRED_VERSION_glib-2.0
>      = "2.18.3"
> ../../conf/distro/include/preferred-om-2009-versions.inc:PREFERRED_VERSION_glib-2.0-native
> = "2.18.0"
> ../../conf/distro/include/angstrom-uclinux-uclibc.inc:USE_NLS_glib-2.0 = "yes"
> ../../conf/distro/include/angstrom-uclinux-uclibc.inc:USE_NLS_glib-2.0-native
> = "yes"
> ../../conf/distro/include/maemo-preferred.inc:PREFERRED_VERSION_glib-2.0
> = "2.6.4"
> ../../conf/distro/include/preferred-gpe-versions-2.8.inc:PREFERRED_VERSION_glib-2.0
> ?= "2.8.6"
> ../../conf/distro/include/sane-toolchain-uclibc.inc:USE_NLS_glib-2.0 = "yes"
> ../../conf/distro/include/sane-toolchain-uclibc.inc:USE_NLS_glib-2.0-native
> = "yes"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLisyDMkyGM64RGpERAldgAKCM3/TP7G540bPars60N9AF9Vcr1QCfe2rR
QHQjbqauqjmMMvFXz5uhNCI=
=BPJk
-----END PGP SIGNATURE-----

Re: [RFC} glib-2.0 cleanup

[Frans Meulenbroeks]

2010/2/28 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> How do you know that some versions aren't used at all? Did you check all
> external overlays?

No. I have no access to them.
But if someone decides to pin an old version in an external overlay,
then I think it is their responsibility to also keep a copy of that
recipe.
And note that they are not gone, they are still in the git if someone
needs them.

Btw if external overlays are a concern then we should never ever
delete a recipe.
>
> But more importantly, what harm do the recipes do to you? Does it offend
> you that there are 26 recipes?

Somewhat yes. Frankly I don't see a use for 26 recipes for all kind of
different versions, some of which are very outdated.

And as you can see from my other message, this is just the tip of the iceberg.
We have about 8000 recipes, but less than 5000 unique ones.
By having less recipes, the parsing time decreases too
(and I am quite aware that there might be some variants needed for some recipes)

And of course with the unused recipes also a lot of outdated patches
go so it will also free some storage space (my recipes directory is
almost 500 M, not that dramatic, but still)

>
> What are you trying to accomplish?
>
> If a recipe isn't doing any harm, just leave it alone. Deleting recipes
> just to please someones sense of aesthetics is the wrong thing to do.

Your opinion has been noted.

>
> What would be a lot better is to fix the latest version for each minor
> release to use things like new style staging, bbclassextend, etc and
> *after* that clean up ask to remove the recipes that weren't updated.
> That way there is a recipe for each minor version so we can check
> regressions quite easily. But the real bonus is that the remaining
> recipes are of good quality. Your proposal doesn't address any QA
> concerns, it just makes the mess a bit smaller

By removing unused versions at least it is clear which recipes need to
be improved and focus can go to those versions.
But if you feel that things like new style staging and bbclassextend
have priority, be my guest.

(actually I found the proposed procedure to convert to new style
staging so cumbersome and time consuming that I gave up on it).

>
> And even then I would rather move recipe + associated patches to
> obsolete than delete it. When we start doing tarball releases
> recipes/obsolete will be a lot more important than it is now.

I'm unaware of plans to do tarball releases (and actually I am not too
sure that it is useful; if you want to, you can download a tarball
from git at every point in time).

Frans

Re: [RFC} glib-2.0 cleanup

[Graham Gower]

On 1 March 2010 06:56, Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote:
> 2010/2/28 Koen Kooi <k.kooi@student.utwente.nl>:
>>
>> But more importantly, what harm do the recipes do to you? Does it offend
>> you that there are 26 recipes?
>
> Somewhat yes. Frankly I don't see a use for 26 recipes for all kind of
> different versions, some of which are very outdated.

What should offend you more is stuff like this:

[grg@rak gcc]$ pwd
/home/grg/oe/openembedded/recipes/gcc
[grg@rak gcc]$ find . -name svn-updates.dpatch -exec ls -l {} \;
-rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
./gcc-4.4.2/debian/svn-updates.dpatch
-rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
./gcc-4.4.1/debian/svn-updates.dpatch
-rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
./gcc-4.3.1/debian/svn-updates.dpatch
-rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
./gcc-4.3.3/debian/svn-updates.dpatch
-rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
./gcc-4.3.4/debian/svn-updates.dpatch
-rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
./gcc-svn/debian/svn-updates.dpatch
-rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
./gcc-4.3.2/debian/svn-updates.dpatch
[grg@rak gcc]$ grep svn-updates *
[grg@rak gcc]$

-Graham

Re: [RFC} glib-2.0 cleanup

[Denys Dmytriyenko]

On Mon, Mar 01, 2010 at 08:10:31AM +1030, Graham Gower wrote:
> On 1 March 2010 06:56, Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote:
> > 2010/2/28 Koen Kooi <k.kooi@student.utwente.nl>:
> >>
> >> But more importantly, what harm do the recipes do to you? Does it offend
> >> you that there are 26 recipes?
> >
> > Somewhat yes. Frankly I don't see a use for 26 recipes for all kind of
> > different versions, some of which are very outdated.
> 
> What should offend you more is stuff like this:
> 
> [grg@rak gcc]$ pwd
> /home/grg/oe/openembedded/recipes/gcc
> [grg@rak gcc]$ find . -name svn-updates.dpatch -exec ls -l {} \;
> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
> ./gcc-4.4.2/debian/svn-updates.dpatch
> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
> ./gcc-4.4.1/debian/svn-updates.dpatch
> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
> ./gcc-4.3.1/debian/svn-updates.dpatch
> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
> ./gcc-4.3.3/debian/svn-updates.dpatch
> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
> ./gcc-4.3.4/debian/svn-updates.dpatch
> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
> ./gcc-svn/debian/svn-updates.dpatch
> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
> ./gcc-4.3.2/debian/svn-updates.dpatch
> [grg@rak gcc]$ grep svn-updates *
> [grg@rak gcc]$

So, there is 125 MB wasted right there... Thanks for the heads up! :)

-- 
Denys

Re: [RFC} glib-2.0 cleanup

[Frans Meulenbroeks]

2010/3/1 Denys Dmytriyenko <denis@denix.org>:
> On Mon, Mar 01, 2010 at 08:10:31AM +1030, Graham Gower wrote:
>> On 1 March 2010 06:56, Frans Meulenbroeks <fransmeulenbroeks@gmail.com> wrote:
>> > 2010/2/28 Koen Kooi <k.kooi@student.utwente.nl>:
>> >>
>> >> But more importantly, what harm do the recipes do to you? Does it offend
>> >> you that there are 26 recipes?
>> >
>> > Somewhat yes. Frankly I don't see a use for 26 recipes for all kind of
>> > different versions, some of which are very outdated.
>>
>> What should offend you more is stuff like this:
>>
>> [grg@rak gcc]$ pwd
>> /home/grg/oe/openembedded/recipes/gcc
>> [grg@rak gcc]$ find . -name svn-updates.dpatch -exec ls -l {} \;
>> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
>> ./gcc-4.4.2/debian/svn-updates.dpatch
>> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
>> ./gcc-4.4.1/debian/svn-updates.dpatch
>> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
>> ./gcc-4.3.1/debian/svn-updates.dpatch
>> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
>> ./gcc-4.3.3/debian/svn-updates.dpatch
>> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
>> ./gcc-4.3.4/debian/svn-updates.dpatch
>> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
>> ./gcc-svn/debian/svn-updates.dpatch
>> -rw-r--r-- 1 grg users 17668056 2009-11-15 12:59
>> ./gcc-4.3.2/debian/svn-updates.dpatch
>> [grg@rak gcc]$ grep svn-updates *
>> [grg@rak gcc]$
>
> So, there is 125 MB wasted right there... Thanks for the heads up! :)

Actually probably just 105 MB, guess we need one copy of it :-)

FM
>
> --
> Denys
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC} glib-2.0 cleanup

[Marcin Juszkiewicz]

Dnia poniedziałek, 1 marca 2010 o 16:20:02 Frans Meulenbroeks napisał(a):
> Actually probably just 105 MB, guess we need one copy of it :-)

We do not use it so we do not need any copy. If someone wants one then we have 
SCM for it.


Regards, 
-- 
JID:      hrw@jabber.org
Website:  http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz

Re: [RFC} glib-2.0 cleanup

[Frans Meulenbroeks]

2010/2/28 Koen Kooi <k.kooi@student.utwente.nl>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> How do you know that some versions aren't used at all? Did you check all
> external overlays?
>
> But more importantly, what harm do the recipes do to you? Does it offend
> you that there are 26 recipes?
>
> What are you trying to accomplish?
>
> If a recipe isn't doing any harm, just leave it alone. Deleting recipes
> just to please someones sense of aesthetics is the wrong thing to do.
>
> What would be a lot better is to fix the latest version for each minor
> release to use things like new style staging, bbclassextend, etc and
> *after* that clean up ask to remove the recipes that weren't updated.

As requested on #oe:

ACK for the proposal above. Seems a good start :-)

Frans

Re: [RFC} glib-2.0 cleanup

[Michael 'Mickey' Lauer]

Am Sonntag, den 28.02.2010, 20:39 +0100 schrieb Frans Meulenbroeks:
> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
> Only a few versions are used (see also the grep below)
> 
> for glib-2.0:
> "2.12.12"
> "2.16.4"
> "2.18.3"
> "2.20.3"
> "2.22.1"
> "2.22.4"
> "2.6.4"
> "2.8.6"
> 
> for glib-2.0-native:
> "2.16.1"
> "2.18.0"
> "2.22.1"
> "2.22.4"
> 
> Both include the last two versions
> Proposal is to remove all versions that are not used.
> 
> How do people feel about this?

Sounds good to me, althoug I'd recommend not removing them but just
moving them out of sight, i.e. in an 'old' folder. That way we could
please both the lets-keep-everything-no-matter-how-rotten and also the
lets-strive-for-few-high-quality recipes.

Cheers,

-- 
:M:

Re: [RFC} glib-2.0 cleanup

[Frans Meulenbroeks]

2010/2/28 Michael 'Mickey' Lauer <mickey@vanille-media.de>:
> Am Sonntag, den 28.02.2010, 20:39 +0100 schrieb Frans Meulenbroeks:
>> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
>> Only a few versions are used (see also the grep below)
>>
>> for glib-2.0:
>> "2.12.12"
>> "2.16.4"
>> "2.18.3"
>> "2.20.3"
>> "2.22.1"
>> "2.22.4"
>> "2.6.4"
>> "2.8.6"
>>
>> for glib-2.0-native:
>> "2.16.1"
>> "2.18.0"
>> "2.22.1"
>> "2.22.4"
>>
>> Both include the last two versions
>> Proposal is to remove all versions that are not used.
>>
>> How do people feel about this?
>
> Sounds good to me, althoug I'd recommend not removing them but just
> moving them out of sight, i.e. in an 'old' folder. That way we could
> please both the lets-keep-everything-no-matter-how-rotten and also the
> lets-strive-for-few-high-quality recipes.

Count me in for the high-quality camp :-)
We could put the legacy recipes in a legacy overlay.
That way they are still there, but if you do not need/want them you
can exclude them.

FM

Re: [RFC} glib-2.0 cleanup

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 28-02-10 22:35, Michael 'Mickey' Lauer wrote:

> please both the lets-keep-everything-no-matter-how-rotten and also the
> lets-strive-for-few-high-quality recipes.

Note that plainly deleting them as proposed does neither, it doesn't
make the remaining recipes "high quality", it just reduces the amount of
recipes.

And I want to reiterate the importance of new-style staging and
leveraging that for BBCLASSEXTEND.
The majority of the TSC has already warmly recommended it.....
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFLi9DAMkyGM64RGpERAmn/AKC85ZIwHVzCV4ufjbKg1+Lt/7whIwCfQ3Hd
k5F2xyrlq8adN5ZZS3YJ7EM=
=ZYzq
-----END PGP SIGNATURE-----

Re: [RFC} glib-2.0 cleanup

[Dr. Michael Lauer]

Am 01.03.2010 um 15:35 schrieb Koen Kooi:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 28-02-10 22:35, Michael 'Mickey' Lauer wrote:
> 
>> please both the lets-keep-everything-no-matter-how-rotten and also the
>> lets-strive-for-few-high-quality recipes.
> 
> Note that plainly deleting them as proposed does neither, it doesn't
> make the remaining recipes "high quality", it just reduces the amount of
> recipes.

Absolutely true, however it is my belief that a load of similar yet different recipes for
a package decrease the motivation to get started and improving something.

> 
> And I want to reiterate the importance of new-style staging and
> leveraging that for BBCLASSEXTEND.

Sure. That's certainly a good step, I just think it's not enough.

:M:

bitbake -b with BBCLASSEXTENDed recipes Was: [RFC} glib-2.0 cleanup

[Martin Jansa]

On Mon, Mar 01, 2010 at 03:43:12PM +0100, Dr. Michael Lauer wrote:
> > And I want to reiterate the importance of new-style staging and
> > leveraging that for BBCLASSEXTEND.
> 
> Sure. That's certainly a good step, I just think it's not enough.

Is it possible to implement some support for old functionality like
bitbake -c clean -b path.to.recipe.with.BBCLASSEXTEND.bb

Now it fails with error like this:
bitbake@jama ~/build.dev.shr.gta $ bitbake -c clean -b ../dev/recipes/libxml/libxml2_2.7.6.bb
ERROR: Parsing error data_fn virtual:native:/OE/dev/recipes/libxml/libxml2_2.7.6.bb and fn /OE/dev/recipes/libxml/libxml2_2.7.6.bb don't match
Traceback (most recent call last):
  File "/usr/bin/bitbake", line 143, in <module>
    main()
  File "/usr/bin/bitbake", line 140, in main
    cooker.cook()
  File "/usr/lib64/python2.6/site-packages/bb/cooker.py", line 608, in cook
    if not self.buildFile(self.configuration.buildfile):
  File "/usr/lib64/python2.6/site-packages/bb/cooker.py", line 500, in buildFile
    taskdata.add_provider(self.configuration.data, self.status, item)
  File "/usr/lib64/python2.6/site-packages/bb/taskdata.py", line 340, in add_provider
    self.add_provider_internal(cfgData, dataCache, item)
  File "/usr/lib64/python2.6/site-packages/bb/taskdata.py", line 376, in add_provider_internal
    eligible, foundUnique = bb.providers.filterProviders(all_p, item, cfgData, dataCache)
  File "/usr/lib64/python2.6/site-packages/bb/providers.py", line 226, in filterProviders
    eligible = _filterProviders(providers, item, cfgData, dataCache)
  File "/usr/lib64/python2.6/site-packages/bb/providers.py", line 188, in _filterProviders
    sortpkg_pn[pn] = sortPriorities(pn, dataCache, pkg_pn)
  File "/usr/lib64/python2.6/site-packages/bb/providers.py", line 46, in sortPriorities
    priority = dataCache.bbfile_priority[f]
KeyError: 'virtual:native:/OE/dev/recipes/libxml/libxml2_2.7.6.bb'

-b was usefull for quick rebuild of modified recipe (ie to rebuild it in workdir
after updating for new staging or BBCLASSEXTEND to see if everything is "the same")

It's really hard to implement something like prefixing -b path with "virtual:native:"
for native variant and use old behavior (clean non-native version) without virtual: prefix)?
Or just nobody cared yet? In this case I would check what can be done.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: bitbake -b with BBCLASSEXTENDed recipes

[Enrico Scholz]

Martin Jansa <martin.jansa@gmail.com> writes:

> Is it possible to implement some support for old functionality like
> bitbake -c clean -b path.to.recipe.with.BBCLASSEXTEND.bb
> ...
> It's really hard to implement something like prefixing -b path with
> "virtual:native:"

Bitbake must be patched for this; see
https://www.cvg.de/people/ensc/0008-bbclassextend.patch


Enrico

Re: bitbake -b with BBCLASSEXTENDed recipes

[Denys Dmytriyenko]

On Mon, Mar 15, 2010 at 05:48:52PM +0100, Enrico Scholz wrote:
> Martin Jansa <martin.jansa@gmail.com> writes:
> 
> > Is it possible to implement some support for old functionality like
> > bitbake -c clean -b path.to.recipe.with.BBCLASSEXTEND.bb
> > ...
> > It's really hard to implement something like prefixing -b path with
> > "virtual:native:"
> 
> Bitbake must be patched for this; see
> https://www.cvg.de/people/ensc/0008-bbclassextend.patch

Care to send it to the bitbake-dev mailing list?

-- 
Denys

Re: bitbake -b with BBCLASSEXTENDed recipes

[Martin Jansa]

On Mon, Mar 15, 2010 at 05:48:52PM +0100, Enrico Scholz wrote:
> Martin Jansa <martin.jansa@gmail.com> writes:
> 
> > Is it possible to implement some support for old functionality like
> > bitbake -c clean -b path.to.recipe.with.BBCLASSEXTEND.bb
> > ...
> > It's really hard to implement something like prefixing -b path with
> > "virtual:native:"
> 
> Bitbake must be patched for this; see
> https://www.cvg.de/people/ensc/0008-bbclassextend.patch

Ahh, great! Thanks for working on this, can you rebase it for bitbake
master? I tried, but it wasn't as easy as it looked first so I gave up.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa                         

Re: bitbake -b with BBCLASSEXTENDed recipes

[Enrico Scholz]

Martin Jansa <martin.jansa@gmail.com> writes:

>> > Is it possible to implement some support for old functionality like
>> > bitbake -c clean -b path.to.recipe.with.BBCLASSEXTEND.bb
>> > ...
>> > It's really hard to implement something like prefixing -b path with
>> > "virtual:native:"
>> 
>> Bitbake must be patched for this; see
>> https://www.cvg.de/people/ensc/0008-bbclassextend.patch
>
> Ahh, great! Thanks for working on this, can you rebase it for bitbake
> master? 

Yes; I will work on it.  But it won't happen before the weekend.



Enrico

Re: [RFC} glib-2.0 cleanup

[Khem Raj]

On Sun, Feb 28, 2010 at 1:35 PM, Michael 'Mickey' Lauer
<mickey@vanille-media.de> wrote:
> Am Sonntag, den 28.02.2010, 20:39 +0100 schrieb Frans Meulenbroeks:
>> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
>> Only a few versions are used (see also the grep below)
>>
>> for glib-2.0:
>> "2.12.12"
>> "2.16.4"
>> "2.18.3"
>> "2.20.3"
>> "2.22.1"
>> "2.22.4"
>> "2.6.4"
>> "2.8.6"
>>
>> for glib-2.0-native:
>> "2.16.1"
>> "2.18.0"
>> "2.22.1"
>> "2.22.4"
>>
>> Both include the last two versions
>> Proposal is to remove all versions that are not used.
>>
>> How do people feel about this?
>
> Sounds good to me, althoug I'd recommend not removing them but just
> moving them out of sight, i.e. in an 'old' folder. That way we could
> please both the lets-keep-everything-no-matter-how-rotten and also the
> lets-strive-for-few-high-quality recipes.
>

FWIW I like the idea of having 'obsolete' recipes so moving them to
recipes/obsolete
may not be so bad.


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

Re: [RFC} glib-2.0 cleanup

[Denys Dmytriyenko]

On Mon, Mar 01, 2010 at 02:11:54PM -0800, Khem Raj wrote:
> On Sun, Feb 28, 2010 at 1:35 PM, Michael 'Mickey' Lauer
> <mickey@vanille-media.de> wrote:
> > Am Sonntag, den 28.02.2010, 20:39 +0100 schrieb Frans Meulenbroeks:
> >> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
> >> Only a few versions are used (see also the grep below)
> >>
> >> for glib-2.0:
> >> "2.12.12"
> >> "2.16.4"
> >> "2.18.3"
> >> "2.20.3"
> >> "2.22.1"
> >> "2.22.4"
> >> "2.6.4"
> >> "2.8.6"
> >>
> >> for glib-2.0-native:
> >> "2.16.1"
> >> "2.18.0"
> >> "2.22.1"
> >> "2.22.4"
> >>
> >> Both include the last two versions
> >> Proposal is to remove all versions that are not used.
> >>
> >> How do people feel about this?
> >
> > Sounds good to me, althoug I'd recommend not removing them but just
> > moving them out of sight, i.e. in an 'old' folder. That way we could
> > please both the lets-keep-everything-no-matter-how-rotten and also the
> > lets-strive-for-few-high-quality recipes.
> >
> 
> FWIW I like the idea of having 'obsolete' recipes so moving them to
> recipes/obsolete may not be so bad.

+1 on this one, since we already have recipes/obsolete in BBMASK by default 
and it will reduce parse time for obsoleted recipes. And git-mv does a nice 
enough job of preserving commit history...

-- 
Denys

Re: [RFC} glib-2.0 cleanup

[Chris Larson]

On Mon, Mar 1, 2010 at 3:30 PM, Denys Dmytriyenko <denis@denix.org> wrote:

> On Mon, Mar 01, 2010 at 02:11:54PM -0800, Khem Raj wrote:
> > On Sun, Feb 28, 2010 at 1:35 PM, Michael 'Mickey' Lauer
> > <mickey@vanille-media.de> wrote:
> > > Am Sonntag, den 28.02.2010, 20:39 +0100 schrieb Frans Meulenbroeks:
> > >> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
> > >> Only a few versions are used (see also the grep below)
> > >>
> > >> for glib-2.0:
> > >> "2.12.12"
> > >> "2.16.4"
> > >> "2.18.3"
> > >> "2.20.3"
> > >> "2.22.1"
> > >> "2.22.4"
> > >> "2.6.4"
> > >> "2.8.6"
> > >>
> > >> for glib-2.0-native:
> > >> "2.16.1"
> > >> "2.18.0"
> > >> "2.22.1"
> > >> "2.22.4"
> > >>
> > >> Both include the last two versions
> > >> Proposal is to remove all versions that are not used.
> > >>
> > >> How do people feel about this?
> > >
> > > Sounds good to me, althoug I'd recommend not removing them but just
> > > moving them out of sight, i.e. in an 'old' folder. That way we could
> > > please both the lets-keep-everything-no-matter-how-rotten and also the
> > > lets-strive-for-few-high-quality recipes.
> > >
> >
> > FWIW I like the idea of having 'obsolete' recipes so moving them to
> > recipes/obsolete may not be so bad.
>
> +1 on this one, since we already have recipes/obsolete in BBMASK by default
> and it will reduce parse time for obsoleted recipes. And git-mv does a nice
> enough job of preserving commit history...


To clarify, git-mv is no different than a git rm + git add.  It's the
analysis tools like git diff-tree/log that know how to identify a copy/move
in a commit.  :)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [RFC} glib-2.0 cleanup

[Khem Raj]

On Mon, Mar 1, 2010 at 2:34 PM, Chris Larson <clarson@kergoth.com> wrote:
> On Mon, Mar 1, 2010 at 3:30 PM, Denys Dmytriyenko <denis@denix.org> wrote:
>
>> On Mon, Mar 01, 2010 at 02:11:54PM -0800, Khem Raj wrote:
>> > On Sun, Feb 28, 2010 at 1:35 PM, Michael 'Mickey' Lauer
>> > <mickey@vanille-media.de> wrote:
>> > > Am Sonntag, den 28.02.2010, 20:39 +0100 schrieb Frans Meulenbroeks:
>> > >> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
>> > >> Only a few versions are used (see also the grep below)
>> > >>
>> > >> for glib-2.0:
>> > >> "2.12.12"
>> > >> "2.16.4"
>> > >> "2.18.3"
>> > >> "2.20.3"
>> > >> "2.22.1"
>> > >> "2.22.4"
>> > >> "2.6.4"
>> > >> "2.8.6"
>> > >>
>> > >> for glib-2.0-native:
>> > >> "2.16.1"
>> > >> "2.18.0"
>> > >> "2.22.1"
>> > >> "2.22.4"
>> > >>
>> > >> Both include the last two versions
>> > >> Proposal is to remove all versions that are not used.
>> > >>
>> > >> How do people feel about this?
>> > >
>> > > Sounds good to me, althoug I'd recommend not removing them but just
>> > > moving them out of sight, i.e. in an 'old' folder. That way we could
>> > > please both the lets-keep-everything-no-matter-how-rotten and also the
>> > > lets-strive-for-few-high-quality recipes.
>> > >
>> >
>> > FWIW I like the idea of having 'obsolete' recipes so moving them to
>> > recipes/obsolete may not be so bad.
>>
>> +1 on this one, since we already have recipes/obsolete in BBMASK by default
>> and it will reduce parse time for obsoleted recipes. And git-mv does a nice
>> enough job of preserving commit history...
>
>
> To clarify, git-mv is no different than a git rm + git add.  It's the
> analysis tools like git diff-tree/log that know how to identify a copy/move
> in a commit.  :)


so git mv will also increase our repo size then ?

> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC} glib-2.0 cleanup

[Chris Larson]

On Mon, Mar 1, 2010 at 3:49 PM, Khem Raj <raj.khem@gmail.com> wrote:

> On Mon, Mar 1, 2010 at 2:34 PM, Chris Larson <clarson@kergoth.com> wrote:
> > On Mon, Mar 1, 2010 at 3:30 PM, Denys Dmytriyenko <denis@denix.org>
> wrote:
> >
> >> On Mon, Mar 01, 2010 at 02:11:54PM -0800, Khem Raj wrote:
> >> > On Sun, Feb 28, 2010 at 1:35 PM, Michael 'Mickey' Lauer
> >> > <mickey@vanille-media.de> wrote:
> >> > > Am Sonntag, den 28.02.2010, 20:39 +0100 schrieb Frans Meulenbroeks:
> >> > >> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
> >> > >> Only a few versions are used (see also the grep below)
> >> > >>
> >> > >> for glib-2.0:
> >> > >> "2.12.12"
> >> > >> "2.16.4"
> >> > >> "2.18.3"
> >> > >> "2.20.3"
> >> > >> "2.22.1"
> >> > >> "2.22.4"
> >> > >> "2.6.4"
> >> > >> "2.8.6"
> >> > >>
> >> > >> for glib-2.0-native:
> >> > >> "2.16.1"
> >> > >> "2.18.0"
> >> > >> "2.22.1"
> >> > >> "2.22.4"
> >> > >>
> >> > >> Both include the last two versions
> >> > >> Proposal is to remove all versions that are not used.
> >> > >>
> >> > >> How do people feel about this?
> >> > >
> >> > > Sounds good to me, althoug I'd recommend not removing them but just
> >> > > moving them out of sight, i.e. in an 'old' folder. That way we could
> >> > > please both the lets-keep-everything-no-matter-how-rotten and also
> the
> >> > > lets-strive-for-few-high-quality recipes.
> >> > >
> >> >
> >> > FWIW I like the idea of having 'obsolete' recipes so moving them to
> >> > recipes/obsolete may not be so bad.
> >>
> >> +1 on this one, since we already have recipes/obsolete in BBMASK by
> default
> >> and it will reduce parse time for obsoleted recipes. And git-mv does a
> nice
> >> enough job of preserving commit history...
> >
> >
> > To clarify, git-mv is no different than a git rm + git add.  It's the
> > analysis tools like git diff-tree/log that know how to identify a
> copy/move
> > in a commit.  :)
>
>
> so git mv will also increase our repo size then ?


What?
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

Re: [RFC} glib-2.0 cleanup

[Khem Raj]

On Mon, Mar 1, 2010 at 2:51 PM, Chris Larson <clarson@kergoth.com> wrote:
> On Mon, Mar 1, 2010 at 3:49 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
>> On Mon, Mar 1, 2010 at 2:34 PM, Chris Larson <clarson@kergoth.com> wrote:
>> > On Mon, Mar 1, 2010 at 3:30 PM, Denys Dmytriyenko <denis@denix.org>
>> wrote:
>> >
>> >> On Mon, Mar 01, 2010 at 02:11:54PM -0800, Khem Raj wrote:
>> >> > On Sun, Feb 28, 2010 at 1:35 PM, Michael 'Mickey' Lauer
>> >> > <mickey@vanille-media.de> wrote:
>> >> > > Am Sonntag, den 28.02.2010, 20:39 +0100 schrieb Frans Meulenbroeks:
>> >> > >> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
>> >> > >> Only a few versions are used (see also the grep below)
>> >> > >>
>> >> > >> for glib-2.0:
>> >> > >> "2.12.12"
>> >> > >> "2.16.4"
>> >> > >> "2.18.3"
>> >> > >> "2.20.3"
>> >> > >> "2.22.1"
>> >> > >> "2.22.4"
>> >> > >> "2.6.4"
>> >> > >> "2.8.6"
>> >> > >>
>> >> > >> for glib-2.0-native:
>> >> > >> "2.16.1"
>> >> > >> "2.18.0"
>> >> > >> "2.22.1"
>> >> > >> "2.22.4"
>> >> > >>
>> >> > >> Both include the last two versions
>> >> > >> Proposal is to remove all versions that are not used.
>> >> > >>
>> >> > >> How do people feel about this?
>> >> > >
>> >> > > Sounds good to me, althoug I'd recommend not removing them but just
>> >> > > moving them out of sight, i.e. in an 'old' folder. That way we could
>> >> > > please both the lets-keep-everything-no-matter-how-rotten and also
>> the
>> >> > > lets-strive-for-few-high-quality recipes.
>> >> > >
>> >> >
>> >> > FWIW I like the idea of having 'obsolete' recipes so moving them to
>> >> > recipes/obsolete may not be so bad.
>> >>
>> >> +1 on this one, since we already have recipes/obsolete in BBMASK by
>> default
>> >> and it will reduce parse time for obsoleted recipes. And git-mv does a
>> nice
>> >> enough job of preserving commit history...
>> >
>> >
>> > To clarify, git-mv is no different than a git rm + git add.  It's the
>> > analysis tools like git diff-tree/log that know how to identify a
>> copy/move
>> > in a commit.  :)
>>
>>
>> so git mv will also increase our repo size then ?
>
>
> What?

because of git add I thought... alright you might have meant the
behavior but not operation
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC} glib-2.0 cleanup

[Chris Larson]

On Mon, Mar 1, 2010 at 4:04 PM, Khem Raj <raj.khem@gmail.com> wrote:

> On Mon, Mar 1, 2010 at 2:51 PM, Chris Larson <clarson@kergoth.com> wrote:
> > On Mon, Mar 1, 2010 at 3:49 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >
> >> On Mon, Mar 1, 2010 at 2:34 PM, Chris Larson <clarson@kergoth.com>
> wrote:
> >> > On Mon, Mar 1, 2010 at 3:30 PM, Denys Dmytriyenko <denis@denix.org>
> >> wrote:
> >> >
> >> >> On Mon, Mar 01, 2010 at 02:11:54PM -0800, Khem Raj wrote:
> >> >> > On Sun, Feb 28, 2010 at 1:35 PM, Michael 'Mickey' Lauer
> >> >> > <mickey@vanille-media.de> wrote:
> >> >> > > Am Sonntag, den 28.02.2010, 20:39 +0100 schrieb Frans
> Meulenbroeks:
> >> >> > >> We have 26 glib-2.0 recipes (and 8 native ones). (see ls below)
> >> >> > >> Only a few versions are used (see also the grep below)
> >> >> > >>
> >> >> > >> for glib-2.0:
> >> >> > >> "2.12.12"
> >> >> > >> "2.16.4"
> >> >> > >> "2.18.3"
> >> >> > >> "2.20.3"
> >> >> > >> "2.22.1"
> >> >> > >> "2.22.4"
> >> >> > >> "2.6.4"
> >> >> > >> "2.8.6"
> >> >> > >>
> >> >> > >> for glib-2.0-native:
> >> >> > >> "2.16.1"
> >> >> > >> "2.18.0"
> >> >> > >> "2.22.1"
> >> >> > >> "2.22.4"
> >> >> > >>
> >> >> > >> Both include the last two versions
> >> >> > >> Proposal is to remove all versions that are not used.
> >> >> > >>
> >> >> > >> How do people feel about this?
> >> >> > >
> >> >> > > Sounds good to me, althoug I'd recommend not removing them but
> just
> >> >> > > moving them out of sight, i.e. in an 'old' folder. That way we
> could
> >> >> > > please both the lets-keep-everything-no-matter-how-rotten and
> also
> >> the
> >> >> > > lets-strive-for-few-high-quality recipes.
> >> >> > >
> >> >> >
> >> >> > FWIW I like the idea of having 'obsolete' recipes so moving them to
> >> >> > recipes/obsolete may not be so bad.
> >> >>
> >> >> +1 on this one, since we already have recipes/obsolete in BBMASK by
> >> default
> >> >> and it will reduce parse time for obsoleted recipes. And git-mv does
> a
> >> nice
> >> >> enough job of preserving commit history...
> >> >
> >> >
> >> > To clarify, git-mv is no different than a git rm + git add.  It's the
> >> > analysis tools like git diff-tree/log that know how to identify a
> >> copy/move
> >> > in a commit.  :)
> >>
> >>
> >> so git mv will also increase our repo size then ?
> >
> >
> > What?
>
> because of git add I thought... alright you might have meant the
> behavior but not operation



Removing a file and adding it in another location does absolutely nothing to
repository size.  The blob object for the file is exactly the same, the only
question is whether that blob is referenced by a given tree object or not.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics