[oe] [RFC} glib-2.0 cleanup

Khem Raj raj.khem at gmail.com
Mon Mar 1 22:49:53 UTC 2010


On Mon, Mar 1, 2010 at 2:34 PM, Chris Larson <clarson at kergoth.com> wrote:
> On Mon, Mar 1, 2010 at 3:30 PM, Denys Dmytriyenko <denis at 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 at 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>




More information about the Openembedded-devel mailing list