quilt-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Quilt-dev] [PATCH 1/4] Ensure quilt(1) documents the correct patche


From: Jean Delvare
Subject: Re: [Quilt-dev] [PATCH 1/4] Ensure quilt(1) documents the correct patches directory
Date: Fri, 24 Feb 2012 16:56:43 +0100
User-agent: KMail/1.12.4 (Linux/2.6.32.54-0.3-pae; KDE/4.3.5; i686; ; )

On Friday 24 February 2012 03:23:59 pm Raphael Hertzog wrote:
> On Fri, 24 Feb 2012, Jean Delvare wrote:
> > On Friday 24 February 2012 08:41:07 am Raphael Hertzog wrote:
> > > We could, it's a small behavioural change but one that makes
> > > sense.
> >
> > I don't see any behavioral change, can you elaborate?
> 
> Actually, I thought (wrongly) that .pc/.quilt_patches was overriding
> QUILT_PATCHES... and thus I believed that we would lose that.

Interestingly this is exactly what I am proposing...

> > AFAICS this is indeed strictly equivalent to the original code.
> > However I am not sure if the code makes sense in the first place.
> > It makes setting QUILT_PATCHES take priority over the value in
> > $QUILT_PC/.quilt_patches. I think it would make more sense to let
> > the value in $QUILT_PC/.quilt_patches have the higher priority. If
> > I set QUILT_PATCHES in my ~/.quiltrc to my preferred patches
> > directory name, and then work on a different project which was
> > initiated with different settings, the project settings should take
> > over my preferences, shouldn't they?
> 
> I guess it can be argued both ways. Environment variables are
>  sometimes used to override settings and sometime used to provide
>  default values.
> 
> Is QUILT_PATCHES mainly used to provide a default value or to
>  override the default value?

I don't remember ever setting QUILT_PATCHES myself, so I am not 
necessarily the best person to answer this question. I can only imagine 
use cases.

> For me it was mainly the latter. That's why I said it could make
>  sense. You seem to see it the other way.

My rationale is: what sense does it make to temporarily override the 
values in .pc/.quilt_patches? If the value is wrong for any reason, the 
proper fix is to edit the file. If the value is correct then I see no 
legitimate reason to override it. Can you come up with a scenario where 
it would make sense? Juggling between different patch directories or 
series files within the same tree can certainly be done, but I don't 
quite get why anyone would want to do that. Plus it would be terribly 
easy to get things wrong.

debian/quilt.make is setting QUILT_PATCHES, but I think it predates the 
introduction of .pc/.quilt_patches.

Setting QUILT_PATCHES when creating a new quilt tree, makes sense. And 
that works with both the current code and my proposal.

My worry with the current code is that it is not possible for a user to 
define his/her preferred QUILT_PATCHES and/or QUILT_SERIES values in 
~/.quiltrc. Doing so would break as soon as the user has to work on 
someone else's tree. Still, our default quiltrc file suggests that this 
should be supported:

# The directory in which patches are found (defaults to "patches").
#QUILT_PATCHES=patches

And again this predates the introduction of .pc/.quilt_patches.

> The only answer that can satisfy everybody is to have 2 variables for
>  the 2 use cases. I'm not sure if it's really needed though.

Agreed, but first someone needs to convince me that overriding the value 
in .pc/.quilt_patches makes any sense.

-- 
Jean Delvare
Suse L3



reply via email to

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