[Quilt-dev] Re: quilt

[Peter Braam]

On Wed, Jul 23, 2003 at 12:42:27PM +0200, Andreas Gruenbacher wrote:
> On Wednesday 23 July 2003 01:59, Peter Braam wrote:
> > 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.

Of course we want it- RPM automatically picks up %doc files.  Installing them
(in the wrong directory that didn't include the version) isn't necessary, and
let to the complaint that rpm found an "installed file which is not 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?

Yes, but to avoid the same error I reported above, it needs to be in the file
list in rpm spec file.

> >      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.

It does nothing of interest: it just sets up the links.

> >   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'.
> 

To avoid a lot of typing I need something like quilt diff -a that creates one
total patch from either all the applied patches or from all the patches in the
series.  No further options, and in particular no typing of the names of
patches should be necessary for that option.

There were two forms of breakage that we have seen in this scenario, but quilt
may have neither problem, hopefully:
 
  1.  concatenating patches allows them to be applied as a total patch.  But
      patch -R can break on such patches because it does not walk the patch
      backward.
  2.  the combinediff program in patchutils was broken and did not always
      produce a correct combined diff.

It seems there are no objections to quilt diff -a as an experiment then.

> >   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? 


Yes, as a warning to indicate to the user: "You've just modified this, do you
first want to run quilt ref?".

I would suggest that "totally refuse" means unless you give: 
  quilt pop -f: restore to previous state, regardless
  quilt pop -R: patch -R last patch, perform even if patch complains

> 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.)

Excellent, that is the starting point for our warning.

> 
> >      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.

OK - but I think the above proposal is so natural, that it does no harm to try
that also.

> 
> >   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.
>

"fork" is vital for our workflow.  Example: 

we have a patch ea-lustre.patch for EA's, which initially applies to
linux-2.4.20.   When we move to linux-2.4.21 our workflow is:

cp series-2.4.20 series-2.4.21
cd /usr/src/linux-2.4.21
quilt push ... repeat
quilt push
 --> error ea-lustre.patch doesn't apply
quilt fork ea-lustre-2.4.21.patch
quilt push -f 
 fix things
quilt ref

In this way we build the new series file. Admittedly without the pc files, it
isn't such a big deal anymore, but this is really a nice work flow for what we
do all the time.

It would be great if quit could accomodate also calling into cvs (or another
scm) to do: 

cvs add "forked patch"

here.

> Would a simple `quilt rename' that renames a patch and updates series.conf do?

I would LOVE a quilt rename in addition, but it would be even nicer if it
could also do 

cvs rm   "original patch"
cvs add  "renamed patch" 

> 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.

We have a "series" directory and a "patches" directory and we do indeed have a
script that 

for p in patches/* ; do
  grep p series/*
  if "grep returned nothing" ; then
     echo $p >> unused patches file
  fi
done

to find what patches we don't use anymore when we remove a series file.  This
not really something that belongs in quilt though.

- Peter -