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

-- 
Julio Merino / @jmmv


Home | Main Index | Thread Index | Old Index