inherit allarch and use RDEPENDS

inherit allarch and use RDEPENDS

[Peter Kjellerstedt]

I just stumbled on the mail below and it raised some questions:

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Martin Jansa
> Sent: den 22 augusti 2016 16:21
> To: openembedded-core@lists.openembedded.org; Joe Slater
> Cc: openembedded-commits@lists.openembedded.org
> Subject: Re: [OE-core] [oe-commits] [openembedded-core] 01/02: systemd-
> compat-units: pkg_postinst() does not work
> 
> On Thu, Aug 18, 2016 at 03:52:33PM +0000, git@git.openembedded.org
> wrote:
> > rpurdie pushed a commit to branch master in repository openembedded-core.

[cut]

> > -RDPEPENDS_${PN} = "systemd"
> > +RDEPENDS_${PN} = "systemd"
> 
> This is good typo fix, but also causes allarch systemd-compat-units to
> RDEPENDS on TUNE_PKGARCH systemd as reported in:
> http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125483.html
> 
> So either please exclude it in layer.conf or drop this runtime
> dependency completely.
> 
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

This is the first I heard about limits to recipes that inherit allarch 
and also use RDEPENDS. So after I read the above, I went and read the 
documentation for the allarch class, which unfortunately did not make 
my understanding much clearer.

Am I to understand that a recipe that inherits allarch cannot have 
runtime dependencies on packages that are built differently per 
architecture or MACHINE? If so, what can it have runtime dependencies 
on? Only other allarch recipes? What are the design limitations behind 
this and is there anything that could be done to change the situation?

As an example, say that I have a recipe that only installs a static 
script, so inheriting allarch is a natural thing to do. However, for 
this script to work it must call a binary built by another recipe so 
it of course RDEPENDS on that other package. Are you saying this is 
wrong? Because that sounds odd to me as it severely limits the 
usefulness of the allarch class.

Another example would be a recipe that installs a static Perl script. 
Can it not inherit allarch while also have a runtime dependency on perl?

If the above is true, why are there no QA tests or similar that catch 
these kind of problems?

//Peter

Re: inherit allarch and use RDEPENDS

[Richard Purdie]

On Tue, 2016-08-23 at 15:15 +0000, Peter Kjellerstedt wrote:
> This is the first I heard about limits to recipes that inherit
> allarch 
> and also use RDEPENDS. So after I read the above, I went and read the
> documentation for the allarch class, which unfortunately did not make
> my understanding much clearer.
> 
> Am I to understand that a recipe that inherits allarch cannot have 
> runtime dependencies on packages that are built differently per 
> architecture or MACHINE? If so, what can it have runtime dependencies
> on? Only other allarch recipes? What are the design limitations 
> behind this and is there anything that could be done to change the
> situation?

It can depend on them, only if you add it to the list of dependencies
in layer.conf, either SIGGEN_EXCLUDERECIPES_ABISAFE or
 SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS. The implication of that is that if
one of these recipes changes, the dependency will not be rebuilt, so
you have to be careful about things like these packages getting
renamed.

Its basically a choice, we can have allarch packages and accept we
can't always rebuild them through the sstate hash changes, or we don't
have allarch packages at all (or have packages that can't have non
-allarch dependencies).


> As an example, say that I have a recipe that only installs a static 
> script, so inheriting allarch is a natural thing to do. However, for 
> this script to work it must call a binary built by another recipe so 
> it of course RDEPENDS on that other package. Are you saying this is 
> wrong? Because that sounds odd to me as it severely limits the 
> usefulness of the allarch class.

You can do this if and only if you list it in layer.conf.

> Another example would be a recipe that installs a static Perl script.
> Can it not inherit allarch while also have a runtime dependency on
> perl?
> 
> If the above is true, why are there no QA tests or similar that catch
> these kind of problems?

We do have sstate hash tests in oe-selftest which would highlight such
a problem.

There are various open bugs complaining about this situation however
I've yet to come up with a way which solves the problem perfectly, much
as I'd like to.

Cheers,

Richard

Re: inherit allarch and use RDEPENDS

[Mike Looijmans]

[-- Attachment #1: Type: text/html, Size: 8132 bytes --]

[-- Attachment #2: imagef3bd97.PNG --]
[-- Type: image/png, Size: 9075 bytes --]

[-- Attachment #3: imagecb41f7.JPG --]
[-- Type: image/jpeg, Size: 1088 bytes --]

[-- Attachment #4: image1bf521.JPG --]
[-- Type: image/jpeg, Size: 1087 bytes --]

[-- Attachment #5: image988d3a.JPG --]
[-- Type: image/jpeg, Size: 1060 bytes --]

Re: inherit allarch and use RDEPENDS

[Richard Purdie]

On Wed, 2016-08-24 at 08:35 +0200, Mike Looijmans wrote:
> First time I've heard about this limitation, I don't understand 
> what's this about either. I've been telling people to put their arch 
> or machine specific code into a seperate package and RDEPEND on it 
> from an allarch package that holds the Python code that calls into
> that.
> 
> We haven't seen any problems with that.
> 
> So what is the bad thing that would happen if we don't set the 
> SIGGEN_EXCLUDE... variables in the layer.conf file?

If you have an allarch recipe X and you depend on a tune or machine
specific package from it, what you'll see is that when you switch
MACHINE (with a different tune), the recipe X will rebuild each time.
This is obviously suboptimal however its not the end of the world. It
is problematic if you're using PR server.

The reason it rebuilds is that its checksum has a dependency on
something which is tune or machine specific, you change MACHINE, the
checksum changes and the allarch recipe's checksum changes.

If we remove the dependency from the task checksum, the problem isn't
there and it doesn't rebuild, however there are some circumstances
where this could be an issue, e.g. if a dependency name was renamed by
debian.bbclass for example.

The mechanism for removing such a dependency is the one I've mentioned
in layer.conf.

You can see if you have a problem with your layers by running:

oe-selftest -r sstatetests.SStateTests.test_sstate_allarch_samesigs

Does that make the issue any clearer?

Related bugs:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7298
https://bugzilla.yoctoproject.org/show_bug.cgi?id=8078
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7724

Cheers,

Richard

Re: inherit allarch and use RDEPENDS

[Mike Looijmans]

[-- Attachment #1: Type: text/html, Size: 8471 bytes --]

[-- Attachment #2: imagec229b8.PNG --]
[-- Type: image/png, Size: 9075 bytes --]

[-- Attachment #3: imagefc50fd.JPG --]
[-- Type: image/jpeg, Size: 1088 bytes --]

[-- Attachment #4: image7d3cad.JPG --]
[-- Type: image/jpeg, Size: 1087 bytes --]

[-- Attachment #5: image3ad530.JPG --]
[-- Type: image/jpeg, Size: 1060 bytes --]