Date: Mon, 31 Aug 1998 12:24:06 +0100 From: Paul Richards <paul@originative.co.uk> To: "'Jordan K. Hubbard'" <jkh@time.cdrom.com>, Matthew Hunt <mph@pobox.com> Cc: "Matthew D. Fuller" <fullermd@futuresouth.com>, committers@FreeBSD.org Subject: RE: make.conf Message-ID: <E40CBF0361C7D111914000C0F0303D1086E7@OCTOPUS>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Jordan K. Hubbard [mailto:jkh@time.cdrom.com] > Sent: Sunday, August 30, 1998 4:58 PM > To: Matthew Hunt > Cc: Matthew D. Fuller; committers@FreeBSD.org > Subject: Re: make.conf > > > I didn't want to join this conversation, but it has an odd > gravitational attraction - even if you know it's going to suck you in > and squish you flat, you just gotta go there for some reason. :-) > > If /etc/make.conf is split at all then it should be split into: > > /usr/src/conf.mk - configuration frobs exclusively > for /usr/src > > /usr/ports/conf.mk - configuration frobs exclusively > for /usr/ports. > > /usr/share/mk/conf.mk - stuff truly global to any > invocation of Bmake > e.g. variables you want both src and ports > (and so on) to get as a base set before > potentially laying their own on top. > I'm a little confused as to what we're trying to solve now :-) There's two issues we've ended up discussing I think. 1) make.conf is not the best place to put all the config variables used to build sources 2) make.conf has become a system config rather than a local config. The problem is that as the project evolves more knobs are added to the build system. These have the be put somewhere, either as documentation or defaults. Whatever you do to make.conf this problem will still arise and if we split it into three or more files then when you add a new knob you'll have to add it to more than one place (if it applies). If the local admin then modifies the setting in these files we've got no further forward because we're now adding new knobs to lots of files and we still have the same upgrade problem because local admins are applying their own changes to all these new files. The only way to stop this is to have a local admin file that is empty but can be used to override system defaults and to make any new additions/changes to a system config file that local admins don't touch. Knobs can be added to this file easily enough and you won't need to update the local admin file, that's their responsibility if they want override the new knob setting. I think this is actually what we have except people have started adding knobs to make.conf rather than bsd.*.mk, which is the point I think Bruce was making in that make.conf is the local override file, we're just not maintaining things properly. We stay fairly disciplined about this with rc.local but we don't seem to treat the build mechanism in the same way. I don't see the point in splitting up make.conf into several conf.mk files that are scattered across the source tree since you might as well put these changes into the Makefiles for that part of the tree, or into the bsd.*.mk files themselves. I can see a good case for allowing overrides to be more localised in the tree, so there's a case for hooks being added to the system files to check for override files as Jordan suggests but I think these should stay empty and changes kept to the global system files when new knobs are added. As to whether make.conf is the right file for overrides, there's only two places that I think you could put local configuration files, one is /etc/ and the other is /var. Any other location isn't local enough, i.e. you might not want the same build settings on different machines that share nfs mounts. With a long term aim of making / read-only and the general practice of /var being a separate partition I think /var/conf would be a good place to put machine specific override files. We could move other user serviceable files from /etc into it as well over time. On a far more contraversial note, some of Unix's configuration mess would actually be suited to a registry style database, Microsoft go much too far with the concept but the principle of a system database that all applications can talk to get this information from is a good idea in my mind. Paul Richards Ph.D. Originative Solutions Ltd
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E40CBF0361C7D111914000C0F0303D1086E7>