[oe] [RFC} glib-2.0 cleanup

[Chris Larson]

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.  :)
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics