Re: Moving rc.d scripts to base.tgz

[uwe%stderr.spb.ru@localhost (Valeriy E. Ushakov)]

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.


> 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.

-uwe