From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] Build reproducibility
Date: Tue, 3 Sep 2013 18:54:05 +0200 [thread overview]
Message-ID: <20130903185405.08314f46@skate> (raw)
In-Reply-To: <e9a540ee2cb82c94c8fa139d228bcde0@sysmic.org>
Dear J?r?me Pouiller,
(Your e-mail client has wrapped the e-mail in a somewhat weird fashion,
leaving only one word one every two lines. Ah, yes a Roundcube Webmail!)
On Tue, 03 Sep 2013 10:15:55 +0200, J?r?me Pouiller wrote:
> I may have an idea to detect cases where a package has a non declared
> dependency.
>
> Inotify may help us to know which files are accessed during build of
> one package.
> Especially, we can know which files in staging/ are accessed. If we
> knew which
> package own which file under staging and we may find what are
> dependencies
> of a package
>
> I already made a system to monitor which files are installed by each
> package
> (http://comments.gmane.org/gmane.comp.lib.uclibc.buildroot/53094). It
> may be adapted to detect owner of staging/ files
This indeed looks interesting. I'm not sure it's really easy to do (on
one side, we need to get the list of files that are installed/owned by
each package, and then whenever a file is accessed, check whether this
file is owned by a package which is part of the dependencies of the
currently built package), but if it's possible, it would quite
certainly raise a number of interesting warnings/issues.
> make allyespackageconfig
Note that an allyespackageconfig doesn't build all packages: they are
some choices in the Buildroot Config.in options, and some packages
depend on the value of those choices. Hence, in a given configuration,
it is not possible to really enable and test all packages.
> make # And monitor which package create which file in
> staging/ for PKG in $PACKAGES[@]; do
> make $PKG-dirclean
> make $PKG # And monitor which files are accessed in staging/
> # process result to get $PKG dependencies
I don't think we should try to infer automatically the dependencies,
but at least show a report of files that were accessed even though they
don't belong to packages that are part of the dependencies.
> done
>
> It would not fix automatically the problem, but an autobuilder may
> send notifications. Inotify instrumentation may stay in a separate
> patch or branch to not be intrusive in Buildroot.
>
> Do you think it would be useful?
It might certainly be useful to do some experiments around this idea
and see if it brings a reasonable result (both in terms of code to
merge, and in terms of warnings/issues that we are able to discover and
fix).
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
prev parent reply other threads:[~2013-09-03 16:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-30 8:31 [Buildroot] Build reproducibility Jérôme Pouiller
2013-08-30 8:31 ` [Buildroot] [PATCH] Fix build reproducibility in Make 3.82 Jérôme Pouiller
2013-09-03 6:13 ` Arnout Vandecappelle
2013-09-03 8:45 ` [Buildroot] [PATCH v2] " Jérôme Pouiller
2013-09-03 9:31 ` Arnout Vandecappelle
2013-09-07 6:06 ` Peter Korsgaard
2013-08-30 11:59 ` [Buildroot] Build reproducibility Thomas De Schampheleire
2013-08-30 12:44 ` Jérôme Pouiller
2013-08-30 12:52 ` Thomas Petazzoni
2013-09-02 8:44 ` Thomas De Schampheleire
2013-09-02 8:53 ` Thomas Petazzoni
2013-09-02 13:18 ` Thomas De Schampheleire
2013-09-03 17:13 ` Thomas Petazzoni
2013-09-05 19:56 ` Thomas De Schampheleire
2013-09-05 20:49 ` Jérôme Pouiller
2013-09-02 16:11 ` Arnout Vandecappelle
2013-09-03 6:26 ` Peter Korsgaard
2013-09-03 7:16 ` Thomas Petazzoni
2013-09-03 7:47 ` Peter Korsgaard
2013-09-03 16:48 ` Thomas Petazzoni
2013-09-03 8:15 ` Jérôme Pouiller
2013-09-03 16:54 ` Thomas Petazzoni [this message]
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=20130903185405.08314f46@skate \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox