PV from filename, not reflected in siginfo?

PV from filename, not reflected in siginfo?

[Olof Johansson]

Hi,

I'm currently investigating reports of bitbake not correctly
handling a type of change to a recipe, where the only change is a
filename rename to update the PV.

With bitbake-dumpsigs:

 ...
 Variable PV value is ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[1] or '1.0'}
 Variable PN value is ${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}
 ...

... with nothing containing the resolved value of PV. I would
expect the computed value of PV to be a part of the siginfo. The
consquence of this seems to be that bitbake doesn't schedule
dependents to be rebuilt, i.e. if I rename the recipe
foo_1.2.3.bb to foo_1.2.4.bb, the recipe foo is rebuilt, but the
image isn't.

I tried some changes:

 - Changing the PV assignment in bitbake.conf to :=. Didn't work,
   got errors that I suspect are related to not being able to
   include foo-${PV}.inc files. The value of PV was clobbered.
   Also played around with using BB_FILENAME instead, but didn't
   help.

 - Changes within Bitbake that assigned the version part of the
   filename to PV when loading new files ending with .bb. This
   worked but is really ugly.

 - Moving the PV assignment into the recipe (as an explicit
   assignment). This works, makes dependents build as expected
   and bitbake-dumpsigs lists the value, but is also ugly.

I suspect this isn't usually a problem in OE-Core, since most
recipe updates requires updates within the recipe as well
(tarball checksums, for instance), but that's not as true for our
internal recipes.

Is this a known issue? Any ideas on how to solve this? Nicer
workarounds?


Thanks,
-- 
olofjn

Re: PV from filename, not reflected in siginfo?

[Richard Purdie]

On Mon, 2016-01-18 at 13:44 +0100, Olof Johansson wrote:
> Hi,
> 
> I'm currently investigating reports of bitbake not correctly
> handling a type of change to a recipe, where the only change is a
> filename rename to update the PV.
> 
> With bitbake-dumpsigs:
> 
>  ...
>  Variable PV value is ${@bb.parse.BBHandler.vars_from_file(d.getVar('
> FILE', False),d)[1] or '1.0'}
>  Variable PN value is ${@bb.parse.BBHandler.vars_from_file(d.getVar('
> FILE', False),d)[0] or 'defaultpkgname'}
>  ...
> 
> ... with nothing containing the resolved value of PV. I would
> expect the computed value of PV to be a part of the siginfo. The
> consquence of this seems to be that bitbake doesn't schedule
> dependents to be rebuilt, i.e. if I rename the recipe
> foo_1.2.3.bb to foo_1.2.4.bb, the recipe foo is rebuilt, but the
> image isn't.
> 
> I tried some changes:
> 
>  - Changing the PV assignment in bitbake.conf to :=. Didn't work,
>    got errors that I suspect are related to not being able to
>    include foo-${PV}.inc files. The value of PV was clobbered.
>    Also played around with using BB_FILENAME instead, but didn't
>    help.
> 
>  - Changes within Bitbake that assigned the version part of the
>    filename to PV when loading new files ending with .bb. This
>    worked but is really ugly.
> 
>  - Moving the PV assignment into the recipe (as an explicit
>    assignment). This works, makes dependents build as expected
>    and bitbake-dumpsigs lists the value, but is also ugly.
> 
> I suspect this isn't usually a problem in OE-Core, since most
> recipe updates requires updates within the recipe as well
> (tarball checksums, for instance), but that's not as true for our
> internal recipes.
> 
> Is this a known issue? Any ideas on how to solve this? Nicer
> workarounds?

It isn't known but I can imagine how this could cause a problem.

I suspect (but am guessing) that:

PV[vardepvalue] = "${PV}"

might happen to fix this...

Cheers,

Richard

Re: PV from filename, not reflected in siginfo?

[Olof Johansson]

On 16-01-18 14:37 +0000, Richard Purdie wrote:
> On Mon, 2016-01-18 at 13:44 +0100, Olof Johansson wrote:
> > Hi,
> > 
> > I'm currently investigating reports of bitbake not correctly
> > handling a type of change to a recipe, where the only change is a
> > filename rename to update the PV.
...
> > Is this a known issue? Any ideas on how to solve this? Nicer
> > workarounds?
> 
> It isn't known but I can imagine how this could cause a problem.
> 
> I suspect (but am guessing) that:
> 
> PV[vardepvalue] = "${PV}"
> 
> might happen to fix this...

Indeed, that works! Thanks a lot! It's not completely obvious to
me why it works, but I'm guessing that this is just a way to make
sure PV is expanded before siginfo is dumped?

Is something based on this acceptable for integration in oe-core,
or is this just a (much) nicer workaround?

-- 
olofjn