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. > 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? For me it was mainly the latter. That's why I said it could make sense. You seem to see it the other way. 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. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ _______________________________________________ Quilt-dev mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/quilt-dev
