Re: [Quilt-dev] Quilt configuration associated with a source code tree/patch series

[Jean Delvare]

Hi Martin, Frank,

Le Monday 05 May 2014 à 00:04 +0200, Martin Quinson a écrit :
> On Mon, Mar 31, 2014 at 10:27:35AM -0400, Frank Bormann wrote:
> > I am new to quilt and just finished to read through the documentation.
> > 
> > I was wondering if quilt has any concept of accepting quiltrc configuration
> > linked to a particular project/source code tree/patch series.
> > 
> > I know that there is ~/.quiltrc which binds to a particular individual and
> > /etc/quilt.quiltrc that binds to a particular system. I was wondering if
> > there is a similar concept where configuration binds to a project/source
> > tree/patch series, that I may be missing. Ideally in such way that any
> > project configuration may be overridden by the system-wide and individual
> > user config files.
> > 
> > The idea is to track changes to a patch series in a version control system
> > and implement branches by having QUILT_SERIES set to different series files
> > for each individual branch.

If that's all you need, I don't think this requires support of
project-specific configuration files. Just set QUILT_SERIES in the
environment before calling quilt the first time, and it will remember
the setting (since quilt version 0.50.) If you need to switch branches
later, just pop all the patches and delete .pc/, and start over.

That being said, I admit I'm not complete sure I fully understand what
you are trying to achieve. If I am way off track, please give a more
concrete example, with your current and desired work flows explained
step-by-step.

Regardless of your actual needs, project-specific configuration files
may be useful to others, so we can still discuss and implement that.

> As far as I know, the ability to configure quilt for a given
> repository is actually *very* limited. Only the patch directory and
> the series file (respectively equivalent to QUILT_PATCHES and
> QUILT_SERIES) are saved in the .pc/ directory (in .pc/.quilt_patches
> and .pc/.quilt_series).

Correct.

> Actually, I'm not sure I'd advise you to mess with these files
> manually. I never temper with the content of .pc myself.

As a general rule you are indeed not supposed to.

> It would be interesting to add the feature that you are speaking of.
> The change could be as simple as the following (untested):
> 
> diff --git a/quilt/scripts/patchfns.in b/quilt/scripts/patchfns.in
> index 5feee9f..d2113ec 100644
> --- a/quilt/scripts/patchfns.in
> +++ b/quilt/scripts/patchfns.in
> @@ -1089,6 +1089,12 @@ fi
>  
>  DB="$QUILT_PC/applied-patches"
>  
> +# Source the repository-specific configuration
> +if [ -e "$QUILT_PATCHES/quiltrc" ]
> +then
> +     source "$QUILT_PATCHES/quiltrc"

This raises a name space question. Although unlikely, "quiltrc" is a
legitimate name for a patch. It might be better to use something even
less likely to collide, such as ".quiltrc" or "quilt.quiltrc". In all
cases, it would be good to prevent a patch under than name from being
created or imported.

BTW I just noticed that we currently don't have such a protection for
the series file, so "quilt new series" is accepted and from there you
can joyfully corrupt or even delete your series file :( This should be
fixed too.

Also I think you want to move the code up in the patchfns file, right
after the user's (or system) quiltrc file is read. Otherwise adding the
default arguments for the current command will be done based on the
wrong settings, which will defeat the point of project-specific
settings.

> +fi
> +
>  if [ -z "$skip_version_check" ] && ! version_check
>  then
>       printf $"The working tree was created by an older version of quilt. 
> Please run 'quilt upgrade'.\n" >&2
> ------>8------
> 
> Note that this would override the user and global settings instead of
> the contrary. Note also that for now, if both /etc/quilt.quiltrc and
> ~/.quiltrc exist, only the ~/.quiltrc is used while the /etc one is
> completely ignored (see at the beginning of bin/quilt.in)
> 
> If you guys like the idea of having a configuration file per
> source tree, I'll cleanup my patch, document this new feature and
> everything. 

I've been thinking about it too, but couldn't make up my mind one way or
another. Thanks to both of you for bringing the topic up again, let's
sort it out now.

If we try to add support for project-specific configuration files, we
need to decide if the project-specific configuration file completely
takes over the user or system configuration file (the same way the user
settings currently do over system settings), or if the project-specific
settings should be merged together with the user settings (we've never
done that before.)

If the first case, it might be inconvenient as some settings really
qualify as user preference and are not tied to a specific project. This
is the case of EDITOR, QUILT_PAGER and QUILT_PATCHES_PREFIX for example.
If we only read the project configuration file, the user will suddenly
miss these settings. That would be very confusing. Unfortunately there
is no automatic way to identify which settings are user-specific.

In the second case, we have to decide which configuration file will be
the base and which configuration file will be the overlay. Letting all
user settings take over project settings would pretty much void the
point of having a project-specific configuration file in the first
place, so obviously it would have to be the other way around. Which is
what Martin proposed if I read the code correctly, so apparently we
agree on that, which is good :)

Note that it then becomes each project's responsibility to come up with
a sane quilt configuration file, and not overwrite settings which only
affect the user and not the project. For example, it would be perfectly
legitimate for a project to set QUILT_REFRESH_ARGS, but QUILT_DIFF_ARGS
should be left to the user to decide.

-- 
Jean Delvare
SUSE L3 Support