tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Moving rc.d scripts to base.tgz



On Fri, Apr 15, 2011 at 8:51 AM, Marc Balmer <mbalmer%netbsd.org@localhost> 
wrote:
> Am 14.04.11 18:34, schrieb Julio Merino:
>> On Thu, Apr 14, 2011 at 2:17 PM, Greg Troxel <gdt%ir.bbn.com@localhost> 
>> wrote:
>>> I think it's basically a reasonable proposal.
>>>
>>> I use etcmanage to update, and it deals with this automatically, so the
>>> current behavior is not causing me problems.
>>>
>>> Two concerns:
>>>
>>>  The upgrade path (to a system with the different set packing) should
>>>  not be disruptive.  I think that needs to be designed before proceeding.
>>>
>>>  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/ 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.
>>
>> (If we had a "system updater" script, we'd just put all this logic into it.)
>>
>>> And then:
>>>
>>>  How far do you go?  What about /etc/services?   Arguably, if that's
>>>  wrong one should fix the sources and reinstall, as including new
>>>  services is a bug fix rather than local configuration.
>>
>> I had missed that.  Yes, this should also be moved... and also daily,
>> weekly and monthly (all of these have conf files and also have .local
>> counterparts).
>
> I am not so sure about /etc/services.  I actually do put local stuff in
> this file.  I would constrain this "update" mechanism to binaries only.
>  services and other files there _are_ user serviceable parts of NetBSD.

Heh, agreed.  For some reason I was mislead to think that services was
a script without me doublechecking... it definitely is not.  It should
not be moved.

-- 
Julio Merino / @jmmv


Home | Main Index | Thread Index | Old Index