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, 9 Dec 2009 16:19:14 +0100
User-agent: KMail/1.9.1

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




reply via email to

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