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 _______________________________________________ Quilt-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/quilt-dev
