[OE-core] [oe-commits] Laurentiu Palcu : mesa: rename mesa-dri recipe to just mesa

[Richard Purdie]

On Mon, 2013-03-25 at 17:01 +0100, Martin Jansa wrote:
> On Mon, Mar 25, 2013 at 03:22:47PM +0000, Richard Purdie wrote:
> > On Mon, 2013-03-25 at 15:52 +0100, Martin Jansa wrote:
> > > On Mon, Mar 25, 2013 at 04:16:54PM +0200, Laurentiu Palcu wrote:
> > > > 
> > > > 
> > > > On 03/25/2013 04:08 PM, Martin Jansa wrote:
> > > > > On Fri, Mar 22, 2013 at 05:05:39PM +0000, git at git.openembedded.org wrote:
> > > > >> Module: openembedded-core.git
> > > > >> Branch: master
> > > > >> Commit: c8bbb9983bcc7cfc5332e89c3e8148505b4ca83f
> > > > >> URL:    http://git.openembedded.org/?p=openembedded-core.git&a=commit;h=c8bbb9983bcc7cfc5332e89c3e8148505b4ca83f
> > > > >>
> > > > >> Author: Laurentiu Palcu <laurentiu.palcu at intel.com>
> > > > >> Date:   Tue Mar 19 18:23:56 2013 +0200
> > > > >>
> > > > >> mesa: rename mesa-dri recipe to just mesa
> > > > >>
> > > > >> Rename mesa-dri recipes to just mesa. Also, replace all references to
> > > > >> mesa-dri in all recipes/configs.
> > > > >>
> > > > >> The reason for this renaming (quote from bugzilla):
> > > > >>
> > > > >> "mesa-dri is a artefact of mesa-xlib existing, which doesn't anymore.
> > > > >> mesa-dri should be renamed to mesa."
> > > > >>
> > > > >> [YOCTO #3385]
> > > > > 
> > > > > How is this supposed to work with incremental builds?
> > > > > 
> > > > > WARNING: The recipe mesa is trying to install files into a shared area
> > > > > when those files already exist. Those files and their manifest location
> > > > > are:
> > > > >    /OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/libGLESv2.so
> > > > >    Matched in manifest-qemux86-64-mesa-dri
> > > > >    /OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/libgbm.la
> > > > >    Matched in manifest-qemux86-64-mesa-dri
> > > > >    /OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/libgbm.so.1.0.0
> > > > >    Matched in manifest-qemux86-64-mesa-dri
> > > > >    /OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/libGLESv2.so.2.0.0
> > > > >    Matched in manifest-qemux86-64-mesa-dri
> > > > >    /OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/libGLESv1_CM.so.1.1.0
> > > > >    Matched in manifest-qemux86-64-mesa-dri
> > > > >    /OE/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/libGLESv1_CM.la
> > > > > .. and lot more ..
> > > > > 
> > > > > from what I remember this means, that old mesa-dri files will be kept in
> > > > > sysroot until I do build from scratch (or sstate-cache). That can be
> > > > > pretty bad when mesa is upgraded to some new version required by other
> > > > > components and my incremental sysroot will still keep old mesa-dri
> > > > > instead.
> > > > > 
> > > > > Yes, I can cleansstate mesa-dri before updating oe-core to include this
> > > > > commit or revert this commit to cleansstate and then remove revert..
> > > > > but that's not something average OE user will understand and do.
> > > > 
> > > > I understand your point here but, frankly, I have no clue how this could
> > > > have been avoided... Are there any means in oe-core that would allow
> > > > removing the old files from the sysroot?
> > > 
> > > I don't think there is something for that now, but the same problem is
> > > for PACKAGE_ARCH changes :/. I'm not sure if such renames and arch
> > > changes are worth it without proper support in OE.
> > > 
> > > Maybe we should introduce something like:
> > > REPLACES = "${TUNE_PKGARCH}:mesa-dri"
> > > 
> > > and use it for PACKAGE_ARCH changes too (e.g. from TUNE_PKGARCH to
> > > allarch)
> > > REPLACES = "${TUNE_PKGARCH}:foo"
> > > This can be a bit more complicated because it would create variable
> > > dependency from new allarch recipe to old PKGARCH (to know which files
> > > need to be removed) :/.
> > 
> > I agree there is a problem in this area and at the moment I'm struggling
> > to see how we can fix it. We probably do need some extra information to
> > hint to sstate what should be removed as currently it can't figure it
> > out.
> > 
> > Can you file an enhancement request with the above idea and a general
> > description of the problem cases we've seen so far?
> 
> done
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4102

Thanks, its well summarised. Not sure when we can look at this but this
will ensure it doesn't get lost and we have some good cases to ensure
work.

Cheers,

Richard