[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