[OE-core] [PATCH 7/7] allarch: Drop various problematic allarch usages

[Martin Jansa]

On Mon, Apr 15, 2013 at 10:49:20AM -0500, Mark Hatle wrote:
> On 4/15/13 10:40 AM, Richard Purdie wrote:
> > On Mon, 2013-04-15 at 10:16 -0500, Mark Hatle wrote:
> >> On 4/15/13 6:07 AM, Richard Purdie wrote:
> >>> In each of these cases allarch is used where the package in question has a
> >>> dependency on things which are not allach and change when MACHINE is changed.
> >>>
> >>> This leads to a rebuild of the package each time MACHINE is switched and
> >>> the sstate checksum changes. The dependencies in question are not suited
> >>> be being marked as ABISAFE.
> >>
> >> In each of these cases, does the contents of the package change when the MACHINE
> >> (or something in that machine) are modified?  If so, I agree they are definitely
> >> not allarch.
> >
> > The contents does not, the sstate checksum however does due to the
> > dependencies. The dependencies are thinks like gtk+ and dbus.
> >
> >> However, if the dependency really doesn't matter, then why isn't ABISAFE correct
> >> in each case?
> >
> > I'm using ABISAFE in this context as shorthand for
> > SIGGEN_EXCLUDERECIPES_ABISAFE and those are defined as things which
> > don't need to rebuild if the dependency changes.
> 
> So this can't be set on a package specific basis?  If that is the case, it may 
> make sense to look into a recipe specific way of declaring a 'lack' of 
> dependency on rebuilding others in the future.
> 
> > gtk+ and dbus both provide libraries and we do want software to rebuild
> > if they change. In the allarch case we could whitelist the dependency
> > however in the general case we shouldn't.
> 
> Ya I agree, I thought it could be done easily on a per-package basis.

Yes it can be
SIGGEN_EXCLUDERECIPES_ABISAFE += "distcc-config->distcc"
should work.

> > Even with that problem addressed somehow, it leaves an issue with ipk
> > multilibs where the distcc-config allarch recipe would always depend
> > upon "distcc" and hence distcc would get pulled into the image,
> > regardless of any other multilib settings (which in turn pulls in gtk+
> > for example). A "lib64-xxx-image" would therefore end up with near
> > enough two copies of half the system due to this. This is something we
> > really need to fix in the opkg implementation of multilibs but I have no
> > idea how.
> 
> This is more then just a problem in opkg, it may be more evident there.. but it 
> is something we should look into as well.
> 
> > Combine the two issues together, neither of which can be addressed at
> > this point of the release cycle and I put the above patch forwards until
> > we can better resolve this.
> >
> > Cheers,
> >
> > Richard
> >
> >
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130415/deb08daa/attachment-0002.sig>