[/run/ and] read-only root
~~
The /run/ idea is shelved, unless someone wants to take up
the torch for it. Run-time state files moved out of /etc/ will
have to go into /var/run/. The program, therefore, is:
1. Wherever possible, state files in /etc/ should be eliminated
On Wed, 2003-04-30 at 15:13, Arthur de Jong wrote:
> I think it should be possible for any program that writes to /etc (it it
> cannot use /var) either to be configurable to store it's data somewhere
> else or use a symlink to store the data somwhere else (e.g. /proc/flashrom
> or /nfsmounteddiskbu
On Wed, Apr 30, 2003 at 03:13:43PM +0200, Arthur de Jong wrote:
> > Do you think having programs write to /etc is a bad thing?
> I think creating /run is worse.
> I think it should be possible for any program that writes to /etc (it it
> cannot use /var) either to be configurable to store it's d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I don't know what it will take to convince you, but I would like you to
> answer these questions:
I also have a problem with adding another toplevel directory and I suspect
there are some more. I haven't read the complete thread (I also have other
Whether we end up with "/run/, resolvconf and read-only root"
depends a lot on whether the maintainers of the affected packages
support the project. So far the response has not been positive.
Here is a quick summary for the packages that were on my TODO list.
Creating /run/
On Apr 29, Jamie Wilkinson <[EMAIL PROTECTED]> wrote:
>Do you think having programs write to /etc is a bad thing?
Yes.
>Where would you put /etc/mtab, to keep /etc sacrosanct?
I would teach mount to follow the /etc/mtab. Actually, I remember that
somebody already did this as he wrote about it o
a) The use case that motivate this proposal:
The debian-devel mailing list,
From: Thomas Hood <[EMAIL PROTECTED]>
Message-Id: <[EMAIL PROTECTED]>
Subject: Re: /run/, resolvconf and read-only root
I would also suggest expanding on these, and presenting a
This one time, at band camp, Jamie Wilkinson wrote:
>This one time, at band camp, Theodore Ts'o wrote:
>>... and those who have tried to explain why it's a bad idea or have
>>concerns have been brushed off. So I've given up for now trying to
>>explain to you folks why I'm not convinced, since I do
This one time, at band camp, Theodore Ts'o wrote:
>... and those who have tried to explain why it's a bad idea or have
>concerns have been brushed off. So I've given up for now trying to
>explain to you folks why I'm not convinced, since I don't have time to
>go pig mud-wrestling, but please don't
On Mon, Apr 28, 2003 at 06:09:10PM -0400, Sam Hartman wrote:
> OK, I think my worst fears are realized. You do actually want to
> solve all the goals I could have imagined you possibly wanting to try
> try and solve.
>
> I think I am very likely to wait until there is a policy change or at
> leas
Hi,
On Mon, Apr 28, 2003 at 05:54:37PM -0400, Sam Hartman wrote:
> > "Jamie" == Jamie Wilkinson <[EMAIL PROTECTED]> writes:
>
> Jamie> This one time, at band camp, Sam Hartman wrote:
> >> Until you get general consensus on a specific goal, I'm
> >> unlikely to accept such changes
OK, I think my worst fears are realized. You do actually want to
solve all the goals I could have imagined you possibly wanting to try
try and solve.
I think I am very likely to wait until there is a policy change or at
least text that would be good guidelines as a policy change before
implementi
> "Jamie" == Jamie Wilkinson <[EMAIL PROTECTED]> writes:
Jamie> This one time, at band camp, Sam Hartman wrote:
>> Until you get general consensus on a specific goal, I'm
>> unlikely to accept such changes if they are submitted to me.
>> As a maintainer I want to be able to loo
On Mon, 2003-04-28 at 00:01, Sam Hartman wrote:
> 1) Why are people mounting root read-only?
"Frank" (Not his real name) has a machine with a local
read-only boot medium and a network connection but no local
hard disk.
"Jane" finds it nice that her /etc/ hierarchy changes only
when she administer
This one time, at band camp, Sam Hartman wrote:
>Until you get general consensus on a specific goal, I'm unlikely to
>accept such changes if they are submitted to me. As a maintainer I
>want to be able to look at some statement and answer the following
>questions:
Hi Sam,
I've just filed the bug
Hi.
I noticed that in order to implement your read-only root proposal, you
propose to modify the pam package.
I'm not really sure I see the justification for read-only /. I can
see several possible justifications and some of the possible goals
conflict.
Until you get general consensus on a spe
This message is about three interdependent goals:
1. To create /run/, which makes it possible ...
2. to implement variable resolver configuration, which will help
3. to make it possible to mount / read-only.
(In the present context, "variable" information is information
that changes during the no
17 matches
Mail list logo
