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@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
