From: Andreas Naumann <email@example.com>
Subject: [Buildroot] [RFC 4/4] board/acmesystems/aria-g25: set BR2_GENIMAGE_CFG_FILES
Date: Mon, 3 Apr 2017 15:01:01 +0200 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
Am 31.03.2017 um 18:34 schrieb Arnout Vandecappelle:
> On 31-03-17 09:46, Andreas Naumann wrote:
>> Hi Phelip,
>> Am 31.03.2017 um 00:51 schrieb Arnout Vandecappelle:
>>> I'm still not entirely sure if this new option is worthwhile. Without it, you
>>> would instead need
>>> Not really complicated either... The only real advantage I see is that it
>>> motivates people more to use genimage (which is otherwise a bit hidden). But for
>>> that, a paragraph or two in docs/manual/customize-post-image.txt would also
>>> work. By the way, even for this series an explanation of the option would be
>>> required in that file.
>>> What do the others think?
>> I have a slightly different use case than most genimage configs in buildroot
>> right now. This is, I use genimage's ability to split my customized rootfs into
>> multiple filesystems in order to give them them ro/writeable and other
>> capabilities as appropriate.
>> Thus to preserve ownership and such I need to run genimage under fakeroot.
> It would indeed make sense to run genimage under fakeroot, but then it'd need
> to have some option to extract the tarball first. Actually, that's something
> that could be added to the genimage.sh script at some point...
>> Currently I do this explicitely in a post image script. An improvement I think
>> about is switching to using the post fakeroot integration which buildroot
>> provides since a while.
>> So unless this becomes some kind of option, your proposed change probably
>> wouldnt work for me.
> It is certainly optional, you can always call genimage directly from you
> post-image script. You can also call the genimage.sh script but I don't know if
> that's useful in your case.
True, Phelip's option [RFC 2/4] doesnt take away other options.
>> What I was thinking about in the past would be a deeper integration of genimage
>> in buildroots filesystem configuration, actually generating the genimage config.
>> But so far it was not worth the effort for me.
> We have considered that in the past. The problem is that genimage doesn't
> support some of the options that we do. Otherwise, however, it would be really
Are you refering to filesystem-specific options or missing ones like
axfs, cloop, cramfs?
> nice to remove all our messy filesystem handling code and just generate a
> genimage.cfg file...
> OTOH we also considered that a full image typically needs more than just a
> single filesystem, so generating a genimage.cfg for part of the image seems a
> bit pointless.
I dont quite understand. Do you mean combining e.g. a standard and a
next prev parent reply other threads:[~2017-04-03 13:01 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 14:51 [Buildroot] [RFC 0/4] add genimage Kconfig entry Etienne Phelip
2017-03-29 14:51 ` [Buildroot] [RFC 1/4] support/scripts: add generic genimage script Etienne Phelip
2017-03-30 22:51 ` Arnout Vandecappelle
2017-04-01 13:50 ` Thomas Petazzoni
2017-03-29 14:51 ` [Buildroot] [RFC 2/4] system: add option to pass genimage config files Etienne Phelip
2017-03-29 14:51 ` [Buildroot] [RFC 3/4] configs/raspberrypi3_defconfig: set BR2_GENIMAGE_CFG_FILES Etienne Phelip
2017-03-29 14:51 ` [Buildroot] [RFC 4/4] board/acmesystems/aria-g25: " Etienne Phelip
2017-03-30 22:51 ` Arnout Vandecappelle
2017-03-31 7:46 ` Andreas Naumann
2017-03-31 16:34 ` Arnout Vandecappelle
2017-04-03 13:01 ` Andreas Naumann [this message]
2017-04-03 13:54 ` Arnout Vandecappelle
2017-04-05 6:38 ` Andreas Naumann
2017-04-05 12:38 ` Arnout Vandecappelle
2017-04-01 13:51 ` Thomas Petazzoni
2017-04-03 9:06 ` Peter Korsgaard
2017-04-03 9:35 ` Arnout Vandecappelle
2017-04-04 21:34 ` Peter Korsgaard
2017-04-05 15:02 ` Arnout Vandecappelle
2017-04-05 16:14 ` Thomas Petazzoni
2017-04-10 13:44 ` Étienne Phélip
2017-04-10 15:06 ` Arnout Vandecappelle
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.