[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Quilt-dev] [PATCH] Remember location of patches and series file
From: |
Jean Delvare |
Subject: |
Re: [Quilt-dev] [PATCH] Remember location of patches and series file |
Date: |
Wed, 16 Dec 2009 11:13:20 +0100 |
User-agent: |
KMail/1.9.1 |
Hi Raphael,
Le mardi 15 décembre 2009 23:44, Raphael Hertzog a écrit :
> Hello Jean,
>
> On Sat, 12 Dec 2009, Jean Delvare wrote:
> > I don't like the feature because, once you realize that
> > .pc/.quilt_patches can be a symbolic link, it becomes clear that you
> > can make patches/ itself a symbolic link to wherever you like and
> > you're done. No need to modify quilt.
>
> Well, no. I a debian source package (format "3.0 (quilt)") all the files
> come from an upstream tarball except the debian sub-directory which comes
> from a debian tarball.
>
> If we create a symlink called "patches" it will be seen as adding a file
> in the upstream tarball and dpkg-source will complain that it doesn't know
> how to "store" that change in a patch. Because any change outside of
> debian is an upstream change that is stored in a new quilt patch
> in debian/patches/.
The software is yours. Just change it to treat the "patches" link
differently.
You are ready and willing to change quilt to fit the specific needs
of a custom software only you (Debian) are using. This is fixing the
conflict in the wrong place IMHO.
> Creating that symlink is not an option for me: while it's ok for
> individual maintainer that prefer creating it instead of setting
> QUILT_PATCHES, it's not a design that I want to force on everyone
> by letting dpkg-source create that symlink when the upstream source
> package might rightfully have its own "patches" directory.
Did you ever see this in practice?
And what would you do if a package happened to have a "debian"
directory (or worse, a "debian" file)?
> I just want dpkg-source to be able to create some files in .pc
> to "pre-configure" the directory so that the maintainer can use
> quilt without worrying about that problem of setting QUILT_PATCHES.
>
> If you prefer that we do create .pc/.quilt_patches as symlink, that's fine
> for me but it seems useless because internally quilt is using an
> environment variable and I don't expect that you would rewrite everything
> to use .pc/.quilt_patches just to support such a feature.
You'd have a point here... if your proposed patch didn't do some
magic trying to relativize paths. If .quilt_patches is supposed to
be the exact file-based equivalent for the $QUILT_PATCHES environment
variable, it should be copied verbatim.
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.
> > see is: "What if you have a directory in your source tree named
> > 'patches', for example?", but as far as I can see this is a
> > theoretical issue, not one somebody has ever hit in practice. And if
>
> It's bad design, sorry.
I don't disagree. But I didn't write quilt in the first place.
> > that it is equally possible that the source tree includes a file or
> > directory named "series" as well, or worse: ".pc". Even the proposed
> > patch can't deal with this case.
>
> Well, by setting the variable by default, the series file would be
> ignored, only the one in debian/patches would be used.
>
> As for .pc, it's documented in the package format that it's reserved, it's
> a dot directory, it's ok.
It is also documented that patches are stored in patches/ by default,
but that doesn't make you happy. After all, ".pc" is a fairly neutral
name, and insanely short at that, so you can't rule out that someone
else happens to use it.
That being said...
I might consider something like your patch if and only if:
* The relative_path stuff is gone; this is complexity we don't need.
* Documentation is updated accordingly.
* 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.
This is all crying for a "quilt setup" command, isn't it?
--
Jean Delvare
Suse L3