[PATCH 1/9] add profile support to pbuilder

[Loïc Minier]

On Sat, Jan 23, 2010, Osamu Aoki wrote:
> Since then, I cleaned source a bit to get it to work and learning 
> "git rebase -i master".

 Ah great; I wasn't sure you were familiar with rebasing yet, and it's a
 bit disruptive if you don't know about it, but you do, so that's going
 to make things easier.

> >  I find this is a bit heavy just for the --profile concept; it is a bit
> >  like --configfile which doesn't require this; the --configfile
> >  "EXTRA_CONFIGFILE" concept is not pretty either though.   :-/
> 
> I understand your concern.  But there seems to be 2 choices:
>  * make this --profile to be the first option before COMMANDS.
>  * make this --profile to be the option losded before all other options.

 Well yes and no; the main problem comes from the fact that we source
 pbuilderrc files /before/ parsing the command-line flags.  If instead
 we would do it *after* setting the flags, and in a way which doesn't
 override what's already set, I think it would work.

 Another approach would be to special case the relevant vars when
 handling --profile: we would override these vars whenever --profile is
 passed.  These would be the vars you currently set with
 ${PROFILE:+$PROFILE/} in pbuilderrc.

> >  I think it would be ok if you would just source the profile at
> >  --profile time.  
> 
> You mean to keep /usr/share/pbuilder/pbuilderrc and /etc/pbuilderrc and
> overide setting of these when --profile is found.  Hmmm...

 /usr/share/pbuilder/pbuilderrc is under our control and is relatively
 easy to handle; /etc/pbuilderrc we could eventually migrate.  But both
 /etc/pbuilderrc and ~/.pbuilderrc could contain anything, including
 overrides such as BASETGZ=foobar.tgz.  I guess we can't just source
 them from the main shell if we want to override them yet source them.

> Just tell me what are the better choices in accepted styles.

 No it's good now; just wanted to mention which scheme I used.

> Your idea is sourcing while --profile is proessed in normal way (not
> preloading).  But key contribution of --profile is not this part.
> 
> It defines $PROFILE which changes from
>   /var/cache/pbuilder/
> to
>   /var/cache/pbuilder/<profile-value>/
> 
> That is the core of my patches.

 These views are not opposed!  I would like the default cache dir and
 basetgz etc. values to change when a profile was set too; I just
 dislike the double parsing of the args and the fact that the sequence
 of args is ignored for --profile versus other arguments.

> I see.  Your idea of --profile is simply source extra configuration
> file. That is where the difference comes in.

 Yes, it's one aspect; I agree that we also want to change the default
 values of BASETGZ, RESULTDIR etc. too.

-- 
Loïc Minier