From: Arnout Vandecappelle <arnout@mind.be>
To: buildroot@busybox.net
Subject: [Buildroot] init script installation policy
Date: Thu, 03 Apr 2014 08:10:44 +0200 [thread overview]
Message-ID: <533CFB64.6000508@mind.be> (raw)
In-Reply-To: <CAAXf6LVtLKm17WOAJ2p+9-+R10vgDYXZFVOYuvXzA9LMOkF9Zw@mail.gmail.com>
On 02/04/14 17:55, Thomas De Schampheleire wrote:
> Hi Nate,
>
> On Wed, Apr 2, 2014 at 3:54 PM, Nathan Ford <nford@westpond.com> wrote:
>> What is the policy for installing init scripts when there is already an
>> init script in the target location? Currently there does not seem to be
>> any consistency. I bring this up as I updated a project to a newer
>> buildroot recently and a package I use went from not installing the init
>> script if it was present, to always installing.
>>
>> For my projects I use a custom skeleton fs and like the fact that I can
>> just store my custom init scripts for the packages I use in the skeleton.
>>
>
> In this case, the recommendation is to use a rootfs overlay rather
> than a custom skeleton. Where the skeleton provides the _initial_
> layout, and packages then add their stuff afterwards, a rootfs overlay
> is copied _after_ all packages have done their job. This means that
> your custom script in the overlay would take precedence over the
> script provided with the package.
That said, our policy currently in many cases is to keep existing files
in /etc rather than overwriting them. However, I think this is wrong,
really: packages should overwrite existing files and custom modifications
should be done in a rootfs overlay, as you say.
When two packages compete for the same file, this at least allows us to
enforce some policy, by adding a dependency (like e.g. is already done
for busybox conflicts). Also, it makes it possible to do a foo-rebuild
after a version bump and get the updated config files.
Regards,
Arnout
>
> Have a look at http://buildroot.uclibc.org/downloads/manual/manual.html#rootfs-custom
>
> Best regards,
> Thomas
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
prev parent reply other threads:[~2014-04-03 6:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-02 13:54 [Buildroot] init script installation policy Nathan Ford
2014-04-02 15:55 ` Thomas De Schampheleire
2014-04-03 6:10 ` Arnout Vandecappelle [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=533CFB64.6000508@mind.be \
--to=arnout@mind.be \
--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.