[buildd-tools-devel] [GIT] sbuild branch user/josch/bug782553 created. release/sbuild-0.67.0-8-g969e6b5

[Johannes Schauer]

Hi,

Quoting Johannes Schauer (2016-01-03 14:37:56)
> The branch, user/josch/bug782553 has been created
>         at  969e6b594a5279394ceac8c5725dcbe4eb735713 (commit)

while working on bug #782553 I was rethinking the sbuild command line options.
There have been several bugs about unexpected behaviour wrt sbuilds
understanding of its command line arguments involving building (or not
building) architecture specific, architecture independent or source packages:
#700317, #782553, #799056, #800748

The fundamental problem is how the command line options map to the internal
options BUILD_ARCH_ALL, BUILD_ARCH_ANY and BUILD_SOURCE. This is especially
true with the option --arch-all-only which (until recently) was the only option
that allowed to change the BUILD_ARCH_ANY option but at the same time changed
BUILD_ARCH_ALL. This resulted in the following being equivalent:

  1) --arch-all --arch-all-only

  2) --no-arch-all --arch-all --arch-all-only

  3) --arch-all-only --arch-all

  4) --no-arch-all --arch-all-only --arch-all

  5) --no-arch-all --arch-all-only

  6) --arch-all-only

  X) there are many more permutations of the above...

but the following being different from the above:

  a) --arch-all-only --no-arch-all

Sure, one could document option order is significant but then one would still
have to document which option changes which internal setting so that as a user
one can figure out in which order to pass the options. I see several problems
with this approach:

 - I believe generally users expect that long and short options are not
   position dependent. Plus, the interface becomes simpler if they are.

 - there should net be at least six ways to express the same thing. How long
   will it take the user to figure out that options 1-6 are actually
   functionally the same? Why allow this?

 - it should not be possible to name mutually conflicting options. Is there a
   purpose in being able to say --no-arch-all --arch-all?

The good news is, that with the --arch-any/--no-arch-any option introduced by
the last release we can now simplify lots of things:

> - Log -----------------------------------------------------------------
> commit 969e6b594a5279394ceac8c5725dcbe4eb735713
> Author: Johannes 'josch' Schauer <josch at mister-muffin.de>
> Date:   Sun Jan 3 14:33:35 2016 +0100
> 
>     make different command line options modifying the same configuration parameter incompatible with each other and remove --arch-all-only in the process (its behaviour can be replicated by using --arch-all --no-arch-any)
> 
> commit c526603d7caf5ea5c77f68dca2d52078a1f35387
> Author: Johannes 'josch' Schauer <josch at mister-muffin.de>
> Date:   Sun Jan 3 12:17:23 2016 +0100
> 
>     Add documentation related to generated build artifacts (closes: #782553)
>     
>      - deprecated --arch-all-only
>      - throw an error if no artifacts are to be created
>      - add references to the command line options to config variables
>        BUILD_ARCH_AND, BUILD_ARCH_ALL and BUILD_SOURCE
>      - add a new section in sbuild man page explaining the
>        --arch-all/no--arch-all, --arch-any/--no-arch-any and
>        --source/--no-source options
> 
> -----------------------------------------------------------------------

Commit c526603d deprecates the --arch-all-only option which can now be
expressed using --arch-all --no-arch-any. It also adds a new section to the man
page which explains how --arch-all/--no-arch-all, arch-any/--no-arch-any and
--source/--no-source work together and in which argument passed to
dpkg-buildpackage they result in any of their combinations.

Commit 969e6b59 goes a step further. It removes the --arch-all-only option
altogether and also implements errors whenever the user tries to pass mutually
exclusive arguments or the same argument with different values. This commit
thus addresses the three problems I listed above.

What do you think?

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/20160103/6ad4d85c/attachment.sig>