Re: [9fans] Re: [sources] 20070410: % cat >/sys/lib/dist/changes/1176262206.1.txt << EOF

[Uriel <uriel99@gmail.com>]

On 4/12/07, Devon H. O'Dell <devon.odell@gmail.com> wrote:
> 2007/4/12, Uriel <uriel99@gmail.com>:
> > >           # uncomment the following for booting other systems
> > >           #ip/dhcpd
> > >           #ip/tftpd
> >
> > Shouldn't optional stuff like this go in cpurc.local anyway?
>
> Sure, but having it here gives a good idea for the kinds of things
> that you would want to put into your cpurc.local.

Then maybe we should provide a sample cpurc.local instead...

>
> > >         + #if(! netstat -n | grep -v 17008 | grep -s il.*Listen)
> > >         + #     aux/listen -q il
> > [...]
> > >         + # cpu specific startup
> > >         + #if(test -e /cfg/$sysname/cpustart)
> > >         + #     . /cfg/$sysname/cpustart
> > >         +
> > >         + #echo `{date} $sysname >>/sys/log/boot
> >
> > Why is all this commented out?
>
> There's no /cfg in the default distribution, for one. IL isn't really
> used per default and isn't very inter-operable. Not sure why the
> bootlog change would be; it seems like a good thing to have in there
> by default. In either case it's giving good ideas for things you may
> want / need in your cpurc.local.

It tests for the /cfg stuff, so if it doesn't exist it should not be a
problem (the code that checks for /cfg/$sysname/cpurc is already
uncommented.)

You might be right about IL, but it might not hurt to have it either,
in any case I agree there should be a way to enable or disable it
without touching the default cpurc.

>
> One thing I'm not sure of still is, if there is a cpurc.local, it may
> want to implement some things dependent on e.g. what if you are
> starting some client script that requires the network to already have
> been initialized. This seems to be what you would end up putting in
> your /cfg/$sysname/cpustart,

We might want a /rc/bin/cpustart.local too?

> > This changes seem to intend to allow local installations to override
> > the default cpurc setup without having to edit it (and therefore get
> > out of sync with sources and need to merge future changes by hand and
> > so on), so I see little reason to leave 'alternative' sections
> > commented out when the local and $sysname specific scripts can take
> > care of that.
>
> We need to have something automatically create /cfg for peoples
> fossils when they upgrade then. You can't just mkdir /cfg.

Having /cfg by default might be a good idea, but I don't think it is a
big deal as long as it is optional, I suspect most small networks can
get by with cpurc.local and maybe a cpustart.local, and if you want
/cfg, you can just create it and cpurc should take advantage of it
automatically.

> > And thanks dho for writing the summaries! Just one small complaint,
> > could you fix the first line of the comments (specially because it is
> > used by convention as subject for the emails)?
>
> I could. How is your script splitting them up though? I was assuming
> that it used those lines to split each change.

For some unknown reason russ refused to have the changes split on his
end, which would be the ideal. I have a script that splits the daily
changes file and puts them in sources, see for example:
/n/sources/contrib/uriel/changes/2007/0410/
and then use that as input for the email notifications.

If someone wants to get a single email per day, they can get a digest
of plan9changes.

To split I use some awk magic to detect text that is not indented,
which is the comments that go over the diffs. See the end of
/n/sources/contrib/uriel/plog for the (awful and fragile) details.


> > Best wishes
> >
> > uriel
>
> If we really wanted to take care of these issues, it'd be worth
> considering the creation of an rc system, but I'm not sure how much
> fire that would cause in the community.

Maybe, but for now I think fixing up what we got seems easy enough and
might be good enough.

uriel