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