On Sun, 2006-04-23 at 20:57 +0200, Michael 'Mickey' Lauer wrote: > Am Dienstag, den 18.04.2006, 02:39 +0200 schrieb Michael 'Mickey' Lauer: > > Holger, thanks for doing this. > > > > Most cases you have spotted are native packages including their > > non-native pendants which inherit classes that add these depends no > > matter whether they have been inherit'ed as part of the "real bbfile" or > > the native one. > > > > I see two possible fixes: > > > > a) manually zap RDEPENDS in the native package right after including the > > non-native one > > b) don't add RDEPENDS when we are in native mode - in the bbclasses. > > > > b) gets my vote. > > > > I'll fix the tetex stuff asap. > > Knock, knock... no other opinions on that?
RDEPENDS do have a role in native packages. Its quite conceivable that a package has runtime dependencies that aren't required at build time for the package. Bitbake's runtime dependency resolution was written to deal with this. Its not that important at the moment but does become important when we deal with multiple bitbake threads which is something I'm working towards. I'd therefore like to see runtime dependencies that make sense. Making native.bbclass nuke them will probably just hide problems rather than fix them. We've already seen improvements to our metadata by the increased number of packages in ASSUME_PROVIDED as its a good way to document our prerequisites. For native packages in the future, I can see an argument something like the following idea: Make native.bbclass set MACHINE to the build machine's arch and always inherit multimachine.conf. The idea has issues but could also remove the need for native packages as every package could have a native version. -native on the end of a package name would have to become something with special handling. Richard _______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
