[oe] [meta-oe][PATCH] krb5: allow to generate empty package
Paul Eggleton
paul.eggleton at linux.intel.com
Sun Mar 5 21:38:22 UTC 2017
On Friday, 3 March 2017 10:28:39 PM NZDT Martin Jansa wrote:
> On Fri, Mar 03, 2017 at 09:24:24AM +0000, Adrian Calianu wrote:
> > From: Martin Jansa [mailto:martin.jansa at gmail.com]
> > Sent: Thursday, March 02, 2017 6:53 PM
> > To: Adrian Calianu <Adrian.Calianu at enea.com>
> > Cc: openembedded-devel <openembedded-devel at lists.openembedded.org>
> > Subject: Re: [oe] [meta-oe][PATCH] krb5: allow to generate empty package
> >
> > > Since other packages may depend on krb5(${PN}).
> >
> > Then fix these other packages.
> > [Adrian Calianu] If you want to install krb5-dev, krb5-dbg
> > packages, they are dependent on krb5 but it does not exists!
>
> Good, so you know which packages to fix.
>
> Installing empty packages to rootfs never helped anyone except HW
> manufactures because we're wasting disk space and processing on useless
> empty packages.
On the other hand, we do have lots of empty packages that exist only to bring
in other packages (e.g. packagegroups).
Specifically in this type of scenario, I do agree that just setting
ALLOW_EMPTY_${PN} isn't enough - that does give you an empty package that
serves no function; worse, it's claiming that krb5 is installed when it really
isn't. There are two workable alternatives:
1) Change PACKAGES so that the recipe doesn't claim that it provides a ${PN}
package when we know it's not going to, so that if you do have a dependency on
it you get an error earlier in the build instead of right at the end during
do_rootfs. At the same time you'd want to change RDEPENDS_${PN}-dev such that
it doesn't depend on the now definitely nonexistent ${PN} package.
2) Have an empty ${PN} package that has RDEPENDS / RRECOMMENDS set to bring in
a sensible subset of the recipe's packages for runtime usage so that you don't
have to having to look at each recipe to determine whether or not it has a
main package. This seems to me to be the least awkward alternative for users,
but of course, it assumes that there is such a sensible subset. The openssh
recipe is an example of this.
FWIW, we have talked about changing the default in OE-Core for the dependency
of ${PN}-dev on ${PN} in order to make this less of a problem (bug 8222 [1]
relates to this). Honestly though I'd prefer people take option 2 above where
possible and then we at least save a few question threads on the mailing list
from new users.
Cheers,
Paul
[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=8222
--
Paul Eggleton
Intel Open Source Technology Centre
More information about the Openembedded-devel
mailing list