Re: packaging issues: some serious, some not so serious

[Sam Ravnborg <sam@ravnborg.org>]

On Tue, Feb 19, 2008 at 07:25:48AM -0500, Robert P. J. Day wrote:
> On Tue, 19 Feb 2008, Sam Ravnborg wrote:
> 
> > On Tue, Feb 19, 2008 at 05:15:10AM -0500, Robert P. J. Day wrote:
> > > On Tue, 19 Feb 2008, Sam Ravnborg wrote:
> > >
> > > > On Tue, Feb 19, 2008 at 04:43:56AM -0500, Robert P. J. Day wrote:
> > > > > On Mon, 18 Feb 2008, Sam Ravnborg wrote:
> > > > >
> > > > > > We could add something like:
> > > > > > diff --git a/Makefile b/Makefile
> > > > > > index 0d585c0..fb5bbc3 100644
> > > > > > --- a/Makefile
> > > > > > +++ b/Makefile
> > > > > > @@ -358,6 +358,11 @@ export MODVERDIR := $(if $(KBUILD_EXTMOD),$(firstword $(KBU
> > > > > >  RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS
> > > > > >  export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --ex
> > > > > >
> > > > > > +# all dirs
> > > > > > +KBUILD_ALL_DIRS := arch block crypto Documentation drivers fs include init
> > > > > > +KBUILD_ALL_DIRS += ipc net samples scripts security sound usr virt
> > > > > > +export KBUILD_ALL_DIRS
> > > > > > +
> > > > >
> > > > > would you not also need to include the regular files at the top of the
> > > > > source tree as well?  for some of the packaging targets, those files
> > > > > should be included as well.
> > > > Yes.
> > > > 'find --max-depth=1 *' or maybe we should provide a seperate list
> > > > for all the relevant filenmaes?
> > >
> > > oh, dang ... it just occurred to me that it's still a good idea to
> > > add dirs like lost+found to the RCS_FIND_IGNORE and RCS_TAR_IGNORE
> > > variables since someone might, weirdly, decide to mount a
> > > subdirectory of the kernel source tree on a separate partition.
> > > unlikely, yes, but it can happen.
> >
> > If they do I would not care at all. We should strive to make the
> > normal cases behave as expected and try to come up with general
> > solutions that does not prevent the more exotic cases.  But trying
> > to imagine all the weird cases and handle them will only result in
> > an un-maintainable mess.
> 
>   i agree.  from what seemed like a simple fix, this has gotten a bit
> out of hand.  i think the easiest solution would be to just come up
> with a single whitelist, and a number of command-specific blacklists,
> and leave it at that.  that's guaranteed to work, and it's trivially
> extensible.
> 
>   so, as an example, define the global whitelist:
> 
> KBUILD_ALL_FILES := COPYING CREDITS Kbuild MAINTAINERS Makefile README REPORTING-BUGS
> KBUILD_ALL_DIRS := arch block crypto Documentation drivers fs include init ipc
> KBUILD_ALL_DIRS += kernel lib mm net samples scripts security sound usr virt
> KBUILD_ALL SRCS := $(KBUILD_ALL_FILES) $(KBUILD_ALL_DIRS)
> export KBUILD_ALL_FILES KBUILD_ALL_DIRS KBUILD_ALL_SRCS
> 
> those variables above are valid for everything and are easily
> augmented.
> 
>   in terms of what are currently called RCS_FIND_IGNORE and
> RCS_TAR_IGNORE, scrap those entirely as they clearly reflect only
> "rcs"-related objects, and just invent new variables:
> 
>   FIND_OBJS_TO_IGNORE := ... both files and dirs ...
>   TAR_OBJS_TO_IGNORE := ... both files and dirs ...
> 
> and that's it.  problem solved.  don't try to partition off the
> RCS-related stuff into its own list of objects, it's not worth the
> trouble.  and note how that entirely solves the lost+found issue, and
> any other issues that might ever arise.
> 
>   thoughts?

Looks good - more or less in line with how I think we should do it.
I assume you cook up a patch for this. Try one of the simple cases first.

	Sam