From: Koen Kooi <k.kooi@student.utwente.nl>
To: openembedded-devel@lists.openembedded.org
Subject: Re: [RFD] increased dependency checking
Date: Sat, 28 Aug 2010 16:49:58 +0200 [thread overview]
Message-ID: <i5b7mm$iso$1@dough.gmane.org> (raw)
In-Reply-To: <AANLkTinFXpPdAkd79h94z70m_8MbamLd48pzR4sLQs34@mail.gmail.com>
-----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-----
next prev parent reply other threads:[~2010-08-28 14:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-28 8:23 [RFD] increased dependency checking Frans Meulenbroeks
2010-08-28 14:49 ` Koen Kooi [this message]
2010-08-28 14:55 ` Chris Larson
2010-08-28 15:05 ` Koen Kooi
2010-08-28 15:24 ` Koen Kooi
2010-08-28 15:43 ` Chris Larson
2010-08-29 8:52 ` Frans Meulenbroeks
2010-08-29 11:28 ` Frans Meulenbroeks
2010-08-30 16:59 ` Vitus Jensen
2010-08-30 17:28 ` C Michael Sundius
2010-09-04 18:11 ` Chris Larson
2010-09-05 7:29 ` Frans Meulenbroeks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='i5b7mm$iso$1@dough.gmane.org' \
--to=k.kooi@student.utwente.nl \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.