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 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.