[oe] [RFD] increased dependency checking

Koen Kooi k.kooi at student.utwente.nl
Sat Aug 28 14:49:58 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As usual you're completely ignoring the impact of this when using
package management, which is probably why you still are clueless why
your openssl fiasco is so much work to fix for distro maintainers.

On 28-08-10 10:23, Frans Meulenbroeks wrote:
> Currently if a package in the DEPENDS list is modified, a package that
> depends on it does not get updated even if explicitly build
> E.g. when I just updated libexif and after that did a bitbake
> mythplugins (which has a DEPENDS on libexif) libexif got build but
> mythplugins did not get rebuild.
> 
> This is not really proper. E.g. if the lib changed a .h file the build
> of the using package could fail, but it could easily get unnoticed as
> one will only become aware of this when forcefully rebuilding that
> using package.
> 
> I think we can do better by better exploiting the timestamp.
> E.g. what about doing it this way:
> 
> If you build a package and the timestamp of e.g. do-install  (or
> do-stage or another pass) of one of your DEPENDS packages is newer
> than your do-install (or another task) then your dependency is most
> likely newer, so you need a rebuild. (preceded with a clean to get rid
> of the old stuff). This should be added to the task list.
> 
> Of course is is not as trivial as I sketch here.
> This whole game needs to be played recursively bottom up.
> So if A depends on B and B depends on C and C gets changed for
> whatever reason, then bitbake A should lead to rebuilding B first.
> 
> A similar thing might also be needed for RDEPENDS.
> If you run time depend on a package that is newer than you are, it
> might also be that there are inconsistencies.
> 
> How does this sound? I assume it will increase the workload of
> bitbake, but I feel this will lead to more stable packages.
> Your feedback is appreciated!
> 
> Frans.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFMeSIVMkyGM64RGpERAk1lAKClt2Qr+fffyiGo7tRdRh99KCjLWACfbZDP
2TlBdc6DaXkJaKKT2ZZu+YY=
=2b/V
-----END PGP SIGNATURE-----





More information about the Openembedded-devel mailing list