Re: Moving rc.d scripts to base.tgz

[Julio Merino <jmmv%NetBSD.org@localhost>]

On Fri, Apr 15, 2011 at 3:35 PM, Valeriy E. Ushakov 
<uwe%stderr.spb.ru@localhost> wrote:
> Julio Merino <jmmv%julipedia.org@localhost> wrote:
>
>> On Thu, Apr 14, 2011 at 2:17 PM, Greg Troxel <gdt%ir.bbn.com@localhost> 
>> wrote:
>>
>>> Two concerns:
>>[...]
>>>  Currently, everything in /etc and /dev/MAKEDEV{,.local} are in
>>>  *etc.tgz.   Programs that munge /etc to do updates need to be able to
>>>  figure out what's in the "should be managed as /etc" and what's
>>>  "non-etc base system".  Probably the mtree files are adequate for
>>>  this, but it bears a little thought.  Looking at how things are now,
>>>  this is arguably not a new problem.
>>
>> That's a good point.  I think the mtree idea is reasonable and should
>> work...  except that, usually, you'd extract base.tgz first and later
>> use etcupdate, which means that by the time you run etcupdate or
>> postinstall you'd have already overridden any previous manual changes.
>> Oops.
>>
>> Without putting too much thought into it right now, the only way I see
>> to do this safely would be to install the files somewhere other than
>> /etc/
>
> How does that solve "local change" problem?  If some script could have
> been locally edited (for whatever reason) at its current location in
> /etc, it can just as well be locally edited at its new location.

Because then you can validate that the obsolete files in /etc/ haven't
been locally modified before overriding them with a symlink to the new
location.

>> and then teach postinstall to install symlinks in /etc/ or
>> similar.  Otherwise, we'd need some transitional period in which
>> postinstall complains loudly about any local modifications and gives
>> you a deadline on which the swap will happen.
>
> Your proposed solution looks more or less isomorphic to the status
> quo, except for a few extra hoops added.  What is currently
> "expressed" by running etcupdate on etc.tgz is "expressed" by,
> effectively, including (part of) etc.tgz in base.tgz and running
> whatever new magic script.  Thus the difference is between
>
> 1) get etc.tgz from release dir
>
> vs.
>
> 2) get (a moral equvivalent of) etc.tgz (already unpacked) by
>   unpacking base.tgz
>
> I fail to see any benefits so far.

I don't follow you here.  The scripts I am referring to are not
supposed to be modified by end users.  They are scripts whose behavior
is (or should be) tunable from configuration files.  As scripts, they
do not belong in etc.tgz and etcupdate should not be bothering anyone
with "differences" in the scripts.  The move from etc.tgz to base.tgz
effectively achieves that: unpacking base.tgz replaces existing files
with newer versions and etcupdate does not bother you with changes to
these files.

-- 
Julio Merino / @jmmv