public inbox for linux-kbuild@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Ravnborg <sam@ravnborg.org>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: kbuild devel list <linux-kbuild@vger.kernel.org>
Subject: Re: packaging issues:  some serious, some not so serious
Date: Tue, 19 Feb 2008 12:49:49 +0100	[thread overview]
Message-ID: <20080219114949.GA5604@uranus.ravnborg.org> (raw)
In-Reply-To: <alpine.LFD.1.00.0802190512540.25846@localhost.localdomain>

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.

	Sam

  reply	other threads:[~2008-02-19 11:49 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-18 16:35 packaging issues: some serious, some not so serious Robert P. J. Day
2008-02-18 18:17 ` Sam Ravnborg
2008-02-18 18:20   ` Robert P. J. Day
2008-02-19  9:43   ` Robert P. J. Day
2008-02-19  9:52     ` Sam Ravnborg
2008-02-19 10:15       ` Robert P. J. Day
2008-02-19 11:49         ` Sam Ravnborg [this message]
2008-02-19 12:25           ` Robert P. J. Day
2008-02-19 13:13             ` Sam Ravnborg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080219114949.GA5604@uranus.ravnborg.org \
    --to=sam@ravnborg.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=rpjday@crashcourse.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox