Brett Lymn <blymn@baesystems.com.au> writes:

> On Sun, Dec 23, 2007 at 09:40:00AM -0500, Greg Troxel wrote:
>> 
>> Do we have precedent for things like this? 
>
> sort of - some of the improvements we see are just things that make
> life easier for someone and they want to share them because they may
> be of general use.

I meant specifically the override-so-not-modified approach.

>> What you are proposing feels like putting
>> hooks in to keep a separate version of the file but without having it
>> appear modified in cvs, and the long-term cleanliness of that seems not
>> so good.
>
> Yes, I want to put a hook in so that the NetBSD source does not appear
> modified in CVS.  What I am building is a product based on a bootable
> NetBSD cdrom, it has very specific requirements which need a modified
> MAKEDEV.tmpl.

In that case, independent from any considerations of what to commit
back, you probably ought to be tracking your own sources in a VCS with
NetBSD on vendor branch.

One of my previous projects had a custom install cd with our modified
system, and we kept netbsd in cvs, and modifed all sorts of things - new
networking subsystem with .h files in set lists, etc.  It was generally
a low-hassle approach, although we did have to import/merge a bunch of
times.

> I could just keep a modified tree and that is what I will do if what I
> have proposed is considered not a good idea but looking at all the
> other things that can be overridden it seems odd that we hard code the
> MAKEDEV.tmpl.

If there is already the notion of overriding files, program lists,
etc. for making CDROMs (rather than having modifed files), then this
seems fine.  I meant only to suggest that if this is the first instance
of this flavor then stepping back to think of other approaches might be
useful, because it feels like solving a problem by adding hooks when
really what you are doing is modifying the sources for a custom build.
The hooks can only go so far, and actual modifications are a much more
general solution.