All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aras Vaichas <aras.vaichas@gmail.com>
To: buildroot@busybox.net
Subject: [Buildroot] makedevs and symbolic links
Date: Thu, 7 Feb 2013 10:14:18 +0000	[thread overview]
Message-ID: <CAJkQPO=A+_7t-dbSP8VutAsen+MvG9J44qx3D6uxKt7C2mBQUg@mail.gmail.com> (raw)
In-Reply-To: <20130206175711.51603415@skate>

On 6 February 2013 16:57, Thomas Petazzoni <
thomas.petazzoni@free-electrons.com> wrote:

> The current design is really:
>
>  * We have a base skeleton in system/skeleton that generally never
>    needs to be modified. The base system/device_table.txt and
>    system/device_table_dev.txt take care of setting the appropriate
>    permissions/ownerships on the files part of the base skeleton.
>
>  * For each project, we encourage people to create a rootfs overlay in
>    board/<company>/<project>/rootfs-overlay/, where they can add their
>    specific configuration files, symbolic links and so on. And a
>    project-specific device table in
>    board/<company>/<project>/device_table.txt sets the appropriate
>    owernship for the files part of the rootfs-overlay.
>

Aaah, I don't have that version of Buildroot. I'm using 2012.11. I can see
from the mailing lists now that patches were added for the "rootfs-overlay".

I might have to leave that until it's in the stable release. I'm currently
documenting how to use Buildroot for my employer (a company with almost
zero Linux knowledge) on their hardware, so I'd rather stick to official
release versions for now. I can update my documentation later.

My current employer wants me to put my Buildroot configuration into their
version control system (MKS). So I am looking at ways that I can avoid
using empty directories and symbolic links to make it diff and MKS
friendly. I guess there's no getting around using multiple files and
scripts to achieve this.

Crazy idea: If only patch/diff handled empty directories, symlinks,
devices, permissions and ownerships. Then it could be done entirely in a
single file that would be 100% friendly in all cases on all operating
systems.

Thanks!

regards

Aras Vaichas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130207/36b694d7/attachment-0001.html>

  reply	other threads:[~2013-02-07 10:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-06 16:17 [Buildroot] makedevs and symbolic links Aras Vaichas
2013-02-06 16:26 ` Thomas Petazzoni
2013-02-06 16:50   ` Aras Vaichas
2013-02-06 16:57     ` Thomas Petazzoni
2013-02-07 10:14       ` Aras Vaichas [this message]
2013-02-07 10:43         ` Thomas Petazzoni
2013-02-07 17:14         ` Arnout Vandecappelle
2013-02-07 21:58         ` [Buildroot] [PATCH] rootfs-overlay: also exclude .empty files Arnout Vandecappelle
2013-02-08  5:15           ` Samuel Martin
2013-02-08 21:18           ` 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='CAJkQPO=A+_7t-dbSP8VutAsen+MvG9J44qx3D6uxKt7C2mBQUg@mail.gmail.com' \
    --to=aras.vaichas@gmail.com \
    --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.