Re: [Quilt-dev] [PATCH] Remember location of patches and series file

[Martin Panter]

> [adding .pc/quiltrc]
> > >> 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)

The way I would like it to work, nobody would be /required/ to change
the ".pc" directory. I'd want Quilt to default to using "patches" and
"patches/series" or whatever it does today, but in particular cases I
would want to force it use something different, without having to set
up silly environment variables all the time.

> . . .
> 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.

Here's the actual reason I wanted to specify the patches and series
file for a specific source tree. My ".pc/quiltrc" file looks like
this:

QUILT_SERIES=series-vad-2
QUILT_PATCHES=../patches

In my "patches" directory there are a few different series files,
sharing some patches, having different "forked" versions of other
patches, and some having extra patches. I put the "patches" outside
the source tree so that I can easily go and delete it all or extract
it in a different directory, and share the patches between different
base versions.

I also wondered if there should be such a thing as a "quilt init"
command, so you could explicitly tell it where the top of the source
tree is, rather than having Quilt search mindlessly up for a directory
called ".pc" or "patches". If this "quilt init" command existed, I'd
expect it to have optional parameters to tell it where "patches" and
"series" are, or where they should be created.

>  > 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/.

Yes, "$QUILT_PATCHES/quiltrc" doesn't help if you want quiltrc to
specify where $QUILT_PATCHES is.

"./quiltrc" at the top of the source tree is a fairly nice solution,
but then Quilt would have to search for "quiltrc" files in addition to
".pc"/"patches" to find the top of the tree.

>  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.

Because "quiltrc" is a shell script, some of these problems could be
worked around by running all such files in a specific order and using
fancy if statements etc.

>  So in the end, the problem you are trying to solve is much more
>  complex than what Raphael wants to implement.