[Buildroot] [PATCH 9/9] core: finalise target in its own location
Yann E. MORIN
yann.morin.1998 at free.fr
Fri Oct 2 07:46:33 UTC 2015
Thomas, All,
On 2015-10-01 23:44 +0200, Thomas Petazzoni spake thusly:
> On Wed, 30 Sep 2015 23:54:52 +0200, Yann E. MORIN wrote:
> > Currently, after all packages have been installed into target/ , we run
> > a sanitising pass called 'target-finalize' on that directory, to:
> > - apply overlays
> > - remove unnecessary files (man, .h, .a ...)
> > - strip files
> > as well as a few other miscellanous cleanups.
> >
> > This means that target/ no longer contains only package-installed files,
> > and that target-finalize might not be idempotent (i.e. sucessive runs of
> > target-finalize may yield different results in target/ ). We're trying
> > pretty hard that all the internal target-finalize hooks are idempotent,
> > whether they are from the core (e.g. installing glibc locales) or
> > provided by packages (e.g. cleaning up perl files).
> >
> > However, that might not be the case for packages from br2-external for
> > example, or under complex situations where a combination of packages
> > does not yield an idempotent sequence (quoting Wikipedia: "a combination
> > of idempotent methods or subroutines is not necessrily idempotent"; see:
> > https://en.wikipedia.org/wiki/Idempotence#Examples ).
[--SNIP--]
>
> To be honest, my initial reaction is: why? What is the benefit? It's
> additional complexity (not so much in the code), but in the user
> visible output directories.
Well, I would say that the user-visible target/ directory, the one we
are currently exposing, is still user-visible, and the only one we want
to expose to users. The new build/target-finalise/ directory introduced
here is not meant to be user-visible. If having that directory in build/
is considered to be user-visible, then I agree this is not that good; we
should really have this directory hidden to the user. It is an internal
step which the user should not meddle with.
> Having idem-potent post-build scripts seems like a good goal to
> achieve. Your only arguments are:
>
> - "this might not be the case for br2-external", but it doesn't
> explain why
A trivial example of a non-idempotent target-finalise hook could be:
define FOO_CREATE_MY_USER
echo "user:x:1234:5678::/home/user:/bin/sh" >>$(TARGET_DIR)/etc/passwd
endef
TARGET_FINALIZE_HOOKS += FOO_CREATE_MY_USER
Yes, this is badly written, but we can't expect this kind of situation
won't happen in real life, especially with br2-external stuff which we
by design can not review. It has hapenned; it will happen again.
> - "under complex situations where a combination of packages does not
> yield an idempotent sequence", which doesn't come with a real-life
> example of such a situation.
Indeed, I have no first-hand example. However, I really said "under
complex situations" just because if such a situation exists, it is
complex by nature and will be difficult to debug.
> So with the current explanation/motivation, I'm inclined to say no to
> this change. I'd be happy to revise my opinion if there are some clearer
> benefits to balance the drawbacks of the additional complexity.
Sure, the changes introduced here are not trivial, by a fair margin...
Thanks!
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
More information about the buildroot
mailing list