Re: xorg recipes cleanup

[Martin Jansa <martin.jansa@gmail.com>]

On Mon, Aug 16, 2010 at 09:25:51PM +0200, Frans Meulenbroeks wrote:
> 2010/8/16 Martin Jansa <martin.jansa@gmail.com>:
> > Hi,
> >
> > all distributions are now using
> > preferred-xorg-versions-X11R7.5.inc or
> > preferred-xorg-versions-live.inc or
> > no preferred-xorg-versions*.inc at all
> >
> > So we can remove some older versions not pinned in those 2
> > to make future maintanance of xorg-* dirs a bit easier.
> >
> > As this is really easy to test (if you apply all 9 and build your
> > favourite target again, no xorg package should be rebuilt - version changed),
> > please test and ACK or don't scream later that you had some strange version
> > preferred from local.conf.
> 
> I could not test, as patch 2 is not on patchwork (and retrieving them
> from gmail is somewhat tricky)

I'm checking why :/ only clue is
bitbake@jama ~/oe $ git send-email 0002-xorg-lib-move-older-not-pinned-versions-to-obsolete-.patch
The following files are 8bit, but do not declare a
Content-Transfer-Encoding.
    0002-xorg-lib-move-older-not-pinned-versions-to-obsolete-.patch
Which 8bit encoding should I declare [UTF-8]? 
<enter>

> Do we indeed want to move this to obsolete? Is there a point in
> retaining it? Why not just rm them (they are still in git)
> Or do we want obsolete to become the graveyard of old recipes?

I usually move it to obsolete where it's not parsed if you have
'standard'
BBFILES := "/OE/dev/recipes/*/*.bb"
and if nobody screams then I'll remove whole obsolete/xorg dir after a
while.

I know it's SCM and I can look to every version in history, but while
it's still in obsolete it's faster to call just diff if I need to check
what changed since previous version.

Regards,
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com