Re: [Quilt-dev] patch for alternate setup mode

[Brian J. Murrell]

On Sat, 2006-02-11 at 15:33 +0100, Andreas Gruenbacher wrote:
> On Thursday 09 February 2006 20:37, Brian J. Murrell wrote:
> 
> > The response I got from this was that something our developers want to
> > be able to do is to pop all the patches and then just point the kernel
> > tree to a different lustre tree (i.e. another branch with possibly
> > different patches on it) and push those without having to unpack another
> > tarball.
> >
> > So it seems that they like not having the unpack step as part of their
> > "setup".  With the size of a kernel tree and the overhead of removing it
> > just to unpack it again to apply a different set of patches, I can
> > understand that.
> 
> Hmm, this sounds like a major recipe for disaster. You will end up with a 
> messed up source tree sooner or later.

(Given my limited exposure to all that quilt does...) As long as quilt
is working properly why would it?  Worst case is the series has a patch
that fails to apply, but even if a push -a was done a pop -a should
clean the tree back up, no?

> If you really want to do that, please 
> use a private shell script or something.

Hrm.  Well, for "external use" (i.e. what we tell users to do) we could
put the "# Source: " line in our series file and have them do the setup
step (which creates the series link -- although for users building
Lustre, I don't think I even care that series is a link).  I guess all
that is missing from quilt as-is for the external user use of quilt is
being able to point to the dir that has the patches that the series file
is referencing.  Or am I just thoroughly confused at this point and this
can be done currently?

For our internal developer use, indeed, our fallback position could be
to simply abandon the setup mode that creates the symlinks (as I
proposed) in a already unpacked tree and ask them to use ln to create
the symlinks in the unpacked source tree.  That all assumes we can count
on symlinks in the unpacked tree continuing to work with push/pop and
friends.  Can we assume that will always be the case?

b.

signature.asc
Description: This is a digitally signed message part