[PATCH 1/9] add profile support to pbuilder
Osamu Aoki
osamu at debian.org
Sun Jan 24 01:11:09 UTC 2010
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
More information about the Pbuilder-maint
mailing list