All of lore.kernel.org
 help / color / mirror / Atom feed
From: Luca Ceresoli <luca@lucaceresoli.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] busybox: provide /etc/mdev.conf if mdev is used
Date: Mon, 11 Jul 2011 12:44:58 +0200	[thread overview]
Message-ID: <4E1AD42A.8000305@lucaceresoli.net> (raw)
In-Reply-To: <8762n9p13n.fsf@macbook.be.48ers.dk>

Peter,

Peter Korsgaard wrote:
>>>>>> "Luca" == Luca Ceresoli<luca@lucaceresoli.net>  writes:
>
> Hi,
>
>   >>  Please use install -D, and only install if the file is not already
>   >>  there in the rootfs.
>
>   Luca>  Will do both changes, but I'd like to better understand why this file
>   Luca>  should not be installed if already present, which differs from how some
>   Luca>  other files are installed.
>
>   Luca>  For example, S10mdev is installed just before mdef.conf (see quoted
>   Luca>  lined above) without -D and without checking for existence.
>
>   Luca>  Is there a general policy about this? I did not find one in the docs,
>   Luca>  but I might have missed it.
>
> The general idea (which isn't followed everywhere unfortunately) is to
> not enforce any policy unless we absolutely have to.
>
> This has to be balanced against us wanting BR to work out of the box. As
> an example we force enable devtmpfs if you build a kernel and have
> devtmpfs /dev option enabled, as it cannot work with the kernel doesn't
> have this enabled. Another example is the ARM EABI selection.
>
> Next to these hard options, that we clearly should enforce we have a
> number of places where we provide sensible defaults. This is typically
> for configuration files. For those we should make it work out of the box
> where possible, but still make it possible to override if the user knows
> better.

Ok, this is much more clear now. Thanks.

> Historically this is done in two ways (the 1st has existed for a
> very long time, the 2nd is relatively new):
>
> - Use a custom rootfs skeleton with tweaked configuration files
> - Use a post-build script to tweak configuration files

There's actually a third way, that is to put custom files in
package/costomize/source. I use it for files that I need to customize, 
nut that would be overwritten by BR if they were in the custom skeleton.

Luca

  reply	other threads:[~2011-07-11 10:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-08 15:47 [Buildroot] [PATCH] busybox: provide /etc/mdev.conf if mdev is used Luca Ceresoli
2011-07-08 18:06 ` Peter Korsgaard
2011-07-11 10:09   ` Luca Ceresoli
2011-07-11 10:23     ` Peter Korsgaard
2011-07-11 10:44       ` Luca Ceresoli [this message]
2011-07-11 11:40         ` Peter Korsgaard
2011-07-11 10:25 ` [Buildroot] [PATCH v2] " Luca Ceresoli
2011-07-11 11:42   ` 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=4E1AD42A.8000305@lucaceresoli.net \
    --to=luca@lucaceresoli.net \
    --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.