[buildd-tools-devel] next sbuild release with decoupled chroot

[Johannes Schauer]

Hi,

Quoting Raphael Hertzog (2016-01-18 16:45:57)
> On Fri, 15 Jan 2016, Johannes Schauer wrote:
> >  2. change the option parsing so that mutually conflicting options cannot be
> >     given anymore at the same time. See [2] for the rationale.
> 
> I'm not sure that this is a good idea... it's quite common to allow the
> last option to win and all programs which are called by wrappers (and
> sbuild is one of them) have often a default invocation which is
> configurable in the wrapper, and you could add "--arch-all" there to
> ensure you build _all.deb by default and at the same time the wrapper lets
> you append more options to further tweak a specific call and here you
> might want to disable that default option with a --no-arch-all that you
> know will be appended after the --arch-all that you set by default.

Okay, I think we can agree that a normal user would never want to make an
sbuild invocation like:

    $ sbuild --arch-all --no-arch-all [...]

This leaves wrappers which might call sbuild like this:

    $ sbuild --arch-all "$@"

Now I can see two reasons why one would want to do it like this:

 1) to have --arch-all be the default when invoking the wrapper without any
    arguments

 2) because whatever the wrapper does *requires* --arch-all

Now if it would continue to be legal to have conflicting options in an sbuild
invocation, then the wrapper would be unable to make sure that sbuild is called
with --arch-all as the user could always supply --no-arch-all and overwrite
that setting. This would then break the wrapper.

If the setting was used just to specify a default, then the wrapper would be
better off supplying a custom sbuildrc and specify the desired defaults there.
Depending on the complexity of the wrapper, a custom sbuildrc has to be used
anyways because many of the interesting internal sbuild settings are not
available on the command line anyways.

So lets try to weigh the advantages of this change against its disadvantages:

Pro:

 - eliminating the confusing possibility of adding contradicting options
 - no need to document how order of parameters matters -> simpler usage
 - ability of wrappers to enforce that an option is switched on

Con:

 - might break existing wrapper scripts that use command line options to
   specify a default

To assess the severity of the "Cons" I'd like to know: is there any sbuild
wrapper that is doing this?

Thanks!

cheers, josch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20160125/78f3fc7f/attachment.sig>