On Fri, Aug 6, 2010 at 6:29 PM, Graham Gower <[email protected]> wrote:
> On 6 August 2010 23:24, Martin Jansa <[email protected]> wrote: > > On Thu, Aug 5, 2010 at 4:15 PM, Chris Larson <[email protected]> > wrote: > >> On Wed, Aug 4, 2010 at 11:58 PM, Graham Gower <[email protected] > >wrote: > >> > >>> rootfs_ipk.bbclass already pulls these in, so avoid some confusion. > >>> > >>> This is totally untested. > >>> > >>> Signed-off-by: Graham Gower <[email protected]> > >>> > >> > >> Looks reasonable to me. > >> > >> Acked-by: Chris Larson <[email protected]> > > > > I've already pushed it, but too late I noticed that only rootfs_ipk is > > handling DISTRO_PACKAGE_MANAGER and rpm/deb based rootfs will probably > > loose DISTRO_PACKAGE_MANAGER from image. > > > > Should I revert now or can we fix it soon? > > > > DISTRO_PACKAGE_MANAGER has been removed altogether. I can't see how it > would work reliably for all images - which is probably why it had > multiple definitions in the first place. And you could still end up > with opkg in your image when setting it to something else, e.g. > minimal-gpe-image and slugos pulled opkg in unconditionally. > DISTRO_PACKAGE_MANAGER could be fixed if it was put in a common > location like image.bbclass. > > What is the intended mechanism for selecting a package manager? > INHERIT = "package_foo" looks like its going to do the trick for ipk > and deb. package_rpm.bbclass might need BOOTSTRAP_EXTRA_RDEPENDS += > "rpm" or something. > BOOTSTRAP_EXTRA_RDEPENDS is a remnant. We wouldn't want them controlling it from there anyway. The fact that I INHERIT package_ipk doesn't mean I'm constructing an ipk image, only that I'm *emitting* packages of that format. IMAGE_PKGTYPE controls which rootfs_* bbclass will be used to construct the image, but that doesn't control which package *manager* for that type will be used, nor whether it should be installed at all (ONLINE_PACKAGE_MANAGEMENT). -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
