tech-userlevel archive

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


mrg (one of the original authors) suggested a few days ago that
rcorder should be rewritten from the ground up. So, because I have
quite a number of better things to do, I have done so.

The proposed new code is here:

Comments? I don't intend to commit this until after branching 5.0.

Some notes:

This code mostly fixes PR 30432 - if you offer the same file twice on
the command line it'll warn and print it twice in the output, but I
don't see that doing anything else really makes sense. Except see

It does not fix PR 30433 or 16061; while some override mechanism is
needed, it's not clear (to me anyway) that either of these proposals
is really the right approach. In particular, the problem I see is that
while we currently don't, it would be nice to be able to run rcorder
on /etc/rc.d/* /usr/pkg/etc/rc.d/* /usr/local/etc/rc.d/*. This breaks
the mirror-directory approach, and it makes the command-line approach
untidy because it requires full paths. Furthermore, both of these
proposals allow only specifying a complete replacement set of
keywords, which isn't robust in the face of system upgrades.

I *think* what we want is, first, to make rcorder work based on
basenames, not full paths, and if two files with the same basename
appear on the command line, have the second suppress the first. Given
a suitable invocation of rcorder, /usr/local/etc/rc.d/foo would
supersede /etc/rc.d/foo, which is the expected behavior. This would,
at least if /usr/local/etc is on /, allow any major customizations by
copying and editing.

Then for overrides I think there should either be a (single) file or a
command-line option (or maybe both) with a syntax something like
"foo:REQUIRES:bar" where foo is the basename of an rc file. To remove
an existing requirement you'd write "foo:REQUIRES:-bar", and if you
really wanted you could remove everything with "foo:*:-*".

I think this solves the evident problems in a more flexible way,
although some of the details (like the exact syntax) aren't yet
clear. Adding support for this to my code won't be that hard.


I still don't know how to arrange things to allow rerunning rcorder
after mountcritlocal and/or mountcritremote in order to deal with rc
files not on the root fs. Stopping partway through isn't that hard;
the question is what should happen if adding more rc files makes the
portion of the graph you've already processed different, and whether
this can cause some files to be skipped entirely, and how to prevent

David A. Holland

Home | Main Index | Thread Index | Old Index