From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] Makefile: check rootfs overlays with BR2_ROOTFS_MERGED_USR enabled
Date: Sat, 5 May 2018 17:21:20 +0200 [thread overview]
Message-ID: <20180505152120.GC14524@scaer> (raw)
In-Reply-To: <87h8nmuoya.fsf@dell.be.48ers.dk>
Peter, All,
On 2018-05-05 17:01 +0200, Peter Korsgaard spake thusly:
> >>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> >> > So, I am pretty much reluctant to see this patch go in.
> > But I'd prefer we keep things simple in Buildroot, and since there is
> > already a way to do it, I don't mind that overlays do not provide this
> > solution. A post-build script is way more versatile when it comes to
> > changing the layout.
>
> Yes, with a post-build script you have full flexibility, but we have
> quite a lot of helper functionality to handle "common" fixups in a
> simpler way than though a post-build script, E.G. stripping, removing
> .py files, overlays, ..
>
> This restriction for overlays isn't obvious and wasn't originally there
> (before the merged /usr support), so it is arguably a regression (but
> for an edge case as this afaik is the first report of it).
I still believe that such *modifications* to the layout be actually not
supported with overlays.
Today, someone wants to be able to overrids /var/log from a symlink to a
directory to be able to store remanent data there. But then, that will
require a modification in fstab to mount an actual filesystem there. And
such a modification would be done by a post-build script (if it comes
from an overlay, there is no way this will work as-is between buildroot
versions, becasue buildroot may add/remove stuff in there as well).
So, a post-build script is really needed anyway...
And then, someone will want to change something else, e.g. a file to a
symlink or a directory to a symlink or whatever...
Also, overlays are not copied under fakeroot (but OK, post-build script
neither, but we have fakeroot-scripts). So, if one wants special rights,
it's not possible with overlays either...
So, really, overlays are not as nice as one may think...
As I said, in the long run, they are more a liability than anything
else.
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. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2018-05-05 15:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-03 12:19 [Buildroot] [PATCH] Makefile: check rootfs overlays with BR2_ROOTFS_MERGED_USR enabled Carlos Santos
2018-05-05 10:01 ` Yann E. MORIN
2018-05-05 13:47 ` Carlos Santos
2018-05-05 14:45 ` Yann E. MORIN
2018-05-05 15:01 ` Peter Korsgaard
2018-05-05 15:21 ` Yann E. MORIN [this message]
2018-05-05 18:13 ` Arnout Vandecappelle
2018-05-05 14:41 ` Peter Korsgaard
2018-05-05 15:06 ` Yann E. MORIN
2018-05-05 15:26 ` Peter Korsgaard
2018-05-05 14:54 ` Peter Korsgaard
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=20180505152120.GC14524@scaer \
--to=yann.morin.1998@free.fr \
--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.