[Quilt-dev] Re: quilt

[Andreas Gruenbacher]

On Wednesday 23 July 2003 01:59, Peter Braam wrote:
> Hi Tom,
>
> Andreas Gruenbacher (cc'd) has built a package called 'quilt' that improves
> and extends the patch scripts of Andrew Morton.   I think we should support
> this work and port our changes over to quilt.  Quilt does not use the pc
> directory explicitly (which is a benefit) and generally is better
> structured.
>
>   0. Quilt is at
>     CVSROOT=:pserver:address@hidden:/cvsroot/quilt
>
>     first cvs login (no password)
>     then cvs co quilt

The project home is <http://savannah.nongnu.org/projects/quilt>. There is a 
development mailing list at 
<http://mail.nongnu.org/mailman/listinfo/quilt-dev>. If you are going to 
contribute to quilt, you should be on that list. I am CC'ing the list now.

>   1. I made a few changes to build a quilt RPM on RedHat 9.  In the
>      Makefile.in, I use rpmbuild, not rpm.

Thanks, I have added an autoconf test that checks for rpmbuild vs. rpm now.

> Secondly also in Makefile.in I
> do not install the doc/README file because it confuses RPM.

What exactly consuses RPM? Is it the doc/ directory? The README contains 
information that is very relevant for starting to work with quilt, so I think 
we want to keep it in the RPM.

>      Finally I added the bash_completion file to the file list in the
>      quilt.spec.in file.

`Make install' is supposed to install bash_completion as 
$RPM_BUILD_ROOT/etc/bash_completion.d/quilt, so that RPM can package it up, 
right?

>   2. For us it is important to verify that we can use the quilt routines as
>      follows:
>      - symlink .../lustre/kernel_patches/patches to a a "patches" directory
>        in the linux source tree.
>      - symlink .../lustre/kernel_patches/foo-series to a "series" file in
> the linux source tree.
>
>      This appears to work.  I do not run quilt setup at all, I just start
>      using it.  [Andreas, are you ok with that usage?]

Yes, that's what I'm doing for kernel work as well. `Quilt setup' is more 
useful for small RPMs with only a handful of patches. Quilt regenerates all 
data in the .pc directory automatically when pushing patches, so you're 
perfectly fine. `Quilt setup' is extremely useful as it creates a proper 
series file with all the patches and their proper `patch -p N' options from 
the spec file, though.

>      It means that our ./prepare-series script can be simpler, and
> indepedent of environment variables.

What does prepare-series do? You may want to take a look at guards, which is 
also ni the quilt cvs. This is what we are using to generate a series file 
from a series file template. The template contains architecture macros; we 
use the script pretty much like:

        guards $(uname -m) < series.conf > series

If prepare-series does more than this, it may be interesting if any of this 
makes sense for the guards script as well.

>   3. We fixed combine-series because combinediff is broken, remember.  We
>      introduced the ~orig files the first time a file was patched, to make
>      aggregate diffs.
>
>      Quilt's has a diff option that could in principle combine the series,
> but I'm worried it may not quite work yet.  Can you add a "combine" command
> to quilt, that mimicks our combine-series command?

What's the difference betwen combinediff and what can be done with `quilt 
diff' already? If `quilt diff' is broken (which I don't believe), I'd much 
rather like to fix it instead of adding a new command that does the same 
thing under a different name.

>      You could also make this an option like quilt diff -a (i.e. diff
> totally everything in the series, or diff everything up to the current top
> patch).

That would be a convenience option to the `-P' and '-c' options of `quilt 
diff'.

>   4. I would like it if quilt pop would NOT remove the patch if it was
>      modified, except when it is explicitly asked.  Of course we need a
>      warning if a pop doesn't go because something was changed.

You mean if quilt detects that the patch has changed, it should totally refuse 
to pop it? Currently it tries if reverse applying leaves the source tree in 
the sate it was in before applying the patch. If that isn't the case, the 
patch is not popped. (If the patch is older than all the source files that 
are affected, `quilt pop' takes a shortcut instead of actually reverse 
applying the patch, but the result is the same unless you mess up the file 
dates.)

>      In that case two force removals are useful:
>        -f  like our poppatch, and like quilt's -f: restore old file.
>        -R  undo the patch.  I'd need an option to do this EVEN if the
>            removal is not clean.  This is to transfer changes from one
> patch to another.  Of course it means that I can do refpatch later on, and
> get the changes there, and also it means that when I push the patch again,
> it will probably not apply. But I can force it then.

For transfering parts of one patch to another, I usually use patch directly, 
followed by `quilt refresh'. Sometimes `quilt diff' is useful for generating 
the diff that shall be moved.

>   5. I'd like our forkpatch to become quilt fork <new-name>
>
>      Andreas, we use forkpatch when a patch that is shared by multiple
> series fails in some source tree.  We then do
>      forkpatch <name, typically  'next-patch + "forked-suffix"'>
>      pushpatch -f
>      refpatch
>      So this is to fix up a patch, but give it a new name.  I believe that
>      with Andreas' quilt forkpatch is as simple as:
>
>        cp patches/`quilt next`.patch patches/<forked-name>
>        edit of the series file which we already have.

That seems useful, but I'm not sure if this is the most efficient workflow. 
You push patches until one rejects, then force apply the patch that failed. 
Maybe the fork should happen inside `quilt push'. On the other hand, the 
result of this isn't intuitive, either.

Would a simple `quilt rename' that renames a patch and updates series.conf do? 
If it's not essential that the old patch file is kept around, that should do 
as well. Adding a fork command isn't a big deal, though.

>      You do not need a new pc file I think.

That happens behind the scenes anyway.

>   6. If Andreas agrees to these changes,

Mostly, yes.

> send him a patch (perhaps you and
> I can be in the credits file).

No problem.

> Perhaps we can even become developers on
> savannah for this and have CVS access.

I'm not opposed to this, but I'd like to see some results first if you don't 
mind.


Thanks,
Andreas.