[oe] dependencies between packages

[C Michael Sundius]

>>
>
> One way to resolve this without bumping all the PR's would be to
> record the PRs of all pacakges it depends on.  (direct and indirect).
> If you rebuild a package and any of the depends packages has a PR that
> is increased, the package is rebuild, even if PR is not changed.
> Another way could be to use the timestamps. If the staging timestamp
> of a package one depends on is newer than the last build of the
> package itself it is rebuild.
> And a third way is to compute all packages that depend on another
> package and rebuild those when the package is changed. However that
> would probably rebuild way too much (everyone depends on glibc so if
> that changes this would become a bitbake world).
>
> However, I think the problem is not the rebuilding of packages, but
> more the deployment of packages. Currently PV + PR are used to
> determine if an upgrade is needed and that kinda gets lost (unless
> opkg also has a version or time check; yuk)..
>
> Frans.
>

Frans,

In your suggestions for solutions to the problem below you described  
that  "if <condition> then the package should be rebuilt".. .it seems  
that this is within the domain of bitbake, since its deciding if the  
tasks should even be run right?

so could you give me a pointer to where I would look to see the part  
of bitbake I would have to modify to add such a check?

I'm not much of a python hacker, though now it looks like I'll have to  
become one. If anyone has a pointer to how bitbake internals are  
organized or advice I'd appreciate it.

My thoughts are that I'll try to work from the 2nd option Frans  
suggested since it is really developers who are wrenching on code and  
recompiling many times in a day... I don't suspect they'll update the  
PR in the recipe each time. (thoughts?)


mike