[PATCH 1/9] add profile support to pbuilder

[Osamu Aoki]

Hi,

After good night sleep and coffee, I think I can do without preloading.

I will read your comment and make another branch after first commit
 ff6cd82193377442ba31f6b247e1a7cd9035c7c1

On Sat, Jan 23, 2010 at 08:09:09PM +0100, Loïc Minier wrote:
> On Sat, Jan 23, 2010, Osamu Aoki wrote:
> > 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.

This is not true.  I agree we can do better.
 
>  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.

That will be the case but need some sanity check too.
Variable override within case and sanity chack after case.
Let me work on it.

> > >  I think it would be ok if you would just source the profile at
> > >  --profile time.  

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

We may be overriding part of it.  Let me think.

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

Understood.

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

I think I just needed sleep to get my head clear.  Coffee time.

Osamu