Hi David, Le vendredi 4 décembre 2009 15:19, David Paleino a écrit : > Jean Delvare wrote: > > > Hi David, > > Le vendredi 4 décembre 2009 11:39, David Paleino a écrit : > >> And, besides that, quilt documentation says that all it's needed to share > >> patches is QUILT_PATCHES (specifically, the series file and the patches). > >> Requiring the user to change things in .pc/ would break this > >> "portability". > >> > >> (cfr. quilt.pdf, §5.3) > > > > I don't quite follow you here. > > > > For one thing, the statement that sharing $QUILT_PATCHES is sufficient > > isn't true even today. quilt supports series files both in > > $QUILT_PATCHES and at the root of the source tree. In the latter case, > > obviously, sharing $QUILT_PATCHES is not sufficient. > > You skipped my parenthesis, eh :) > "specifically, the series file and the patches" -- so my statement still > holds.
OK, we agree on that. > > For another, I fail to see how .pc/quiltrc would alter the current > > situation. The fact that QUILT_PATCHES could be redefined there does > > not change the fact that the contents of $QUILT_PATCHES is what you > > want to share (modulo the exception mentioned above.) > > If you only share $QUILT_PATCHES (modulo the exception above), you're not > giving some additional information needed to apply the patches -- i.e. > QUILT_PATCHES itself. Here I'm totally lost, sorry. You share $QUILT_PATCHES but QUILT_PATCHES is missing? Doh. Maybe try with a concrete example? > (but that could be any QUILT_* variable) Most QUILT_* variables are not related to the patch series but to the default behavior of the quilt commands. The only variable (other than QUILT_PATCHES) that seems relevant here is QUILT_SERIES. Not sure how often this one is used in practice. > On the other hand, what would be the drawbacks of having yet-another- > special-file (like "series"), called "quiltrc" (or ".quiltrc"), to be looked > in $QUILT_PATCHES/quiltrc, ./quiltrc and the like? > This way one could specify per-project quilt variables, and keep them also > in a $VCS (while .pc could not, since it's meant as a temporary directory, > or at least that's how I understood it). > Did I miss something? You are right that .pc is temporary and wouldn't be too happy in a $VCS. That being said, I can't see any problem with putting selected files in this directory under version control (as Raphael is proposing.) I am under the impression that your own proposal is a snake biting its own tail. You want quiltrc to be looked for in $QUILT_PATCHES but you also want to be able to redefine QUILT_PATCHES in that configuration file! Obviously that doesn't work. The extra configuration file can only go in a well defined place, that is, the root of the source code or .pc/. Anyway, as a summary, I can't see that much difference between your proposal and Raphael's. He adds separate files to define the location of the series file and the patches, when you put both defines in a single file. Other than that it seems to be pretty much the same. Oh, your proposal can set other quilt settings, but then it becomes quite confusing what we should do if customer settings disagree with per-repository settings. There are certainly cases where the user would want to use the file to set mandatory settings for a project (for example the refresh options, to enforce a specific format for the patches) while in other cases the file would only contain project-specific defaults which should still be overridden by the user's own settings. And things get even worse when you consider that the same QUILT variable can list more than one option, and that it may be desirable, in some cases, to merge both settings rather than picking one of them and ignoring the other. So in the end, the problem you are trying to solve is much more complex than what Raphael wants to implement. > > Lastly, quilt.pdf is a piece of documentation, not a specification. > > Ack :) -- Jean Delvare Suse L3 _______________________________________________ Quilt-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/quilt-dev
