From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Laszlo Papp <lpapp@kde.org>
Cc: daniel.elstner@kdab.com,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: ROOT_HOME: /home/root
Date: Wed, 29 Jan 2014 12:52:53 +0000 [thread overview]
Message-ID: <1390999973.24655.64.camel@ted> (raw)
In-Reply-To: <CAOMwXhOUo7tUOdAno5-ebFxEqO9LW_C4bz1KghFfEg6_TUe40g@mail.gmail.com>
On Wed, 2014-01-29 at 12:32 +0000, Laszlo Papp wrote:
> Hi,
>
> Is there any obstacle why this cannot be /root as per default Unix
> philosophy [1]?
>
> It is not an unusual that the /home partition is a separate, and the
> sysadmins would like to manage the core system without getting that
> partition mounted, etc.
>
> It is true that it would be possible to work that around, but /root as
> a default just feels so much more natural on a Unix system.
>
> What I currently see after talking to a few people, the people keep
> changing it in their layer (distribution) config. It looks sub-optimal
> at first, but perhaps there are still valid reasons to keep this
> around?
>
> I was told on IRC the first embedded debian may have done it to keep
> rootfs read-only. First, you can remount the root partition on jffs2,
> ubifs, etc... as R/W.
>
> Even if you could not, you can have a separate /root partition which
> is a good idea anyway to keep the super-user separate from the
> "regular" users. If that is not OK, there is still the option for the
> minority to override it to /home/root if really needed, but I
> personally do not think it should be...
>
> So, all in all, I am in favor of changing this back to /root to be
> more linux-y and well-separated from the normal users.
>
> Unfortunately, it would lead to some breakages out there when they
> update Yocto, so it may not be acceptable in this project. I do not
> know the rules. The migration could be aided though with some proper
> documentation.
These directories can be configured by the user extremely easily. By
having a default of /home/root/ we can catch software that has issues
with relocation of that. Having the writeable user data in one directory
like this is useful for several classes of embedded style devices.
So to be honest I don't see a pressing reason to change this.
Cheers,
Richard
next prev parent reply other threads:[~2014-01-29 12:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-29 12:32 ROOT_HOME: /home/root Laszlo Papp
2014-01-29 12:37 ` Phil Blundell
2014-01-29 12:39 ` Laszlo Papp
2014-01-29 14:06 ` Koen Kooi
2014-01-29 15:04 ` Laszlo Papp
2014-01-29 15:16 ` Koen Kooi
2014-01-29 16:23 ` Laszlo Papp
2014-01-29 12:52 ` Richard Purdie [this message]
2014-01-29 12:59 ` Laszlo Papp
2014-01-29 13:13 ` Richard Purdie
2014-01-29 13:29 ` Laszlo Papp
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=1390999973.24655.64.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=daniel.elstner@kdab.com \
--cc=lpapp@kde.org \
--cc=openembedded-core@lists.openembedded.org \
/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.