Re: [Quilt-dev] [PATCH] Remember location of patches and series file

[Jean Delvare]

Hi Raphael,

Le mercredi 16 décembre 2009 23:57, Raphael Hertzog a écrit :
> On Wed, 16 Dec 2009, Jean Delvare wrote:
> > And what would you do if a package happened to have a "debian"
> > directory (or worse, a "debian" file)?
> 
> With the old source package format, it was a pain and we usually repacked
> the upstream tarball. With the new source format, the debian dir/file is
> replaced by the content of the debian tarball.

So you might lose required data.

BTW, there is a debian directory in the quilt package itself. If you
blast it when unpacking it, what is it good for? Can't we get rid of
it?

> > Reading http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557623
> > I seem to understand that once again this piece of code was written
> > to workaround a problem in Debian's internal tools.
> 
> It's not working around, it's just adding a feature so that both tools
> can be better used _together_. We have been using quilt for years without
> that feature but those that do all have been creating a .quiltrc like
> this:
> for where in ./ ../ ../../ ../../../ ../../../../ ../../../../../; do
>         if [ -e ${where}debian/rules -a -d ${where}debian/patches ]; then
>                 export QUILT_PATCHES=debian/patches
>                 break
>         fi
> done

A nice illustration of the power of quilt configuration files being bash
shell scripts :)

But this is not what I was talking about. I was referring to the
relativize_path() function, which was added for the following reason,
quoting the debian bug:

"The reason why
relativize_path is needed is that dpkg-source uses absolute paths when
unpacking a 3.0 (quilt) package and tools like dch rename the top
directory when changing the (upstream) version. Without relative paths
quilt would then not find the patches dir and series file or, when
the directory is copied, even use the original ones. I think that would
be highly confusing to the user."

So, the _debian_ tools are using absolute paths where quilt expects
relative paths, and you were trying to adjust quilt rather than
fixing your own tools.

> I'd like to avoid this by setting up QUILT_PATCHES automatically thanks
> to the new files in .pc.

Yes, I got the idea by now ;)

> > * The root finder algorithm is also updated accordingly; as discussed
> >   with Martin a few days ago, looking for $QUILT_PATCHES no longer
> >   works with your proposed change, you must also look for .pc in case
> >   this is where $QUILT_PATCHES is defined. This won't be bullet-proof
> >   even then, but it already wasn't and I guess it never really was
> >   meant to be.
> 
> The root finder algorithm is after QUILT_PATCHES has been set from
> $QUILT_PC/.quilt_patches so it's already working as expected, no?

Well, no. $QUILT_PC is relative to the root, so you can't read
$QUILT_PC/.quilt_patches if you haven't found the root first. So, in
its current state, your patch is broken when quilt is not run from
the root.

> Or do you mean that we should look for .pc in parent directories
> too?

Yes, that's what I meant. And it should do so _before_ trying to read
$QUILT_PC/.quilt_patches or $QUILT_PC/.quilt_series.

> Once I have those answers, I'll try to come up with an updated patch
> (maybe not very soon, I'm a father since a few days and need some time to
> get used to my new life).

Best wishes. Take your time and enjoy every minute :) See you in a
few months.

> > This is all crying for a "quilt setup" command, isn't it?
> 
> What would be its interface ?
> 
> quilt setup [patch-dir [series-file]]
> 
> and it would create .pc in the current directory with the
> given parameters for .pc/.quilt_patches & .pc/.quilt_series ?

For example, yes. Although I think I would prefer:

quilt setup [--patches=patch-dir] [--series=series-file] [dir]

for flexibility and clarity. But this can all be discussed.

-- 
Jean Delvare
Suse L3