Re: libata update posted

[Jeff Garzik <jgarzik@pobox.com>]

Andries Brouwer wrote:
> On Sun, Sep 14, 2003 at 01:26:21PM -0400, Jeff Garzik wrote:
> 
> 
>>>This shows why defkeymap.c is not generated in the kernel build
>>>but distributed.
>>
>>There is a difference between distributing generated files, and checking 
>>generated files into a repository...  I do not advocate changing the 
>>tarball, just the BK repo behind it.
> 
> 
> So you would like to remove defkeymap.c from the bitkeeper repository.
> Can you briefly explain why?
> I am not a bk user so have no feeling for what one would like bk to do.
> 
> But it seems to me that if defkeymap.c is only a generated file when
> no kbd headers have changed, while in the opposite case one needs a
> private version of loadkeys until the next version of kbd has been
> distributed, it is easier to regard it as part of the kernel source.

defkeymap.c is _always_ a generated file.  However, some environments 
lack the capability to generate it (properly).

My motivation is not bitkeeper-specific:  I dislike the practice of 
checking build-generated files into an SCM of any sort.  That sort of 
stuff should be handled by the maintainer, when generating the release 
patches and tarballs.  aic7xxx is another example

Package developers (read: kernel hackers) are expected to have a correct 
environment to rebuild generated files properly.  Package builders are 
only expected to have a minimal build environment, with stuff like 
configure scripts, yacc/lex output, defkeymap, and similar things 
pre-generated from a canonical source (the maintainer).

The GNOME guys recognized this distinction between hackers and builders 
a long time ago.  When you check things out of GNOME cvs, you get _just_ 
the sources.  One must run ./autogen.sh to generate the 
autoconf/automake/libtool junk needed to actually build successfully.

	Jeff