quilt-dev
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]