[buildd-tools-devel] Bug#799056: Bug#799056: [PATCH] Add --source-only flag for only building the source package

[Miguel A. Colón Vélez]

> There seems to be a spurious hunk that escapes the minus in dpkg-buildpackage.
> This should be part of a separate commit. On the other hand it seems that groff
> upstream renders also un-escaped minuses as HYPHEN-MINUS. The lintian warning
> is also no more. See #785353.
>
> The docs for --source-only say:
>
>  | The \-\-arch=\fIarchitecture\fP option can still be used to specify the
>  | architecture used to build the package.
>
> I do not see how this is relevant here and I also do not see how a user could
> think that the --arch option could *not* still be used together with
> --source-only. If you are worried that the user might not know how the --arch
> option works then additional explanation of what it does should go into the
> docs for the --arch option.

Well, I just reused the --arch-all-only documentation. The same
argument about --arch not being needed could be used there. Also, that
is why the spurious escaping happened since I was reading it an only
one hyphened was not escaped so I escaped it for purposes of
copy/paste but forgot to remove it when making the patch. Also, thanks
for pointing out that the lintian tag was removed.

>
> While we are at documentation:
>
> Quoting Miguel A. Colón Vélez (2015-09-15 11:51:02)
>> It's more elegant than cheating a bit and doing "-s --arch-all-only
>> --no-arch-all" and then doing --post-build-commands "dput local-sbuild
>> %r/%b/${FILE}_source.changes".
>
> Reading the source code I can see how above ends up having the same effect as
> the --source-only option you introduce in your patch. But your new option makes
> this only even more confusing. For example the following:
>
>  --source-only --arch-all-only
>
> Would be equal to:
>
>  --source --arch-all-only
>
> Would be equal to:
>
>  --arch-all-only --source
>
> Would be equal to:
>
>  --arch-all-only --no-arch-all --arch-all --source
>
> None of this is obvious from the man page and the new --source-only option
> makes it even more confusing. Thus, I'd really appreciate if
>
>  - the documentation could be enhanced to explain that there are the three
>    options BUILD_ARCH_ALL, BUILD_ARCH_ANY and BUILD_SOURCE
>  - that those options are further documented in the man page of sbuild.conf
>  - which command line option sets either of these to what with what effect
>  - how the order of command line option potentially overwrites an earlier
>    option
>  - maybe group --arch-all-only, --source, --source-only and --no-arch-all in a
>    separate section to do this explanation

The current behavior is just reading the options from left to right
and overwriting any settings set by previous flags. This also happens
with make-binNMU/binNMU and arch/build/host in which depending on the
input order settings get overwritten. Those are more straight forward
in a sense.

The current issue as related to BUILD_*  would have been easily solved
if --arch-all-only never existed and instead was implemented as an
option to just switch BUILD_ARCH_ANY on and off. There is already a
flag A|arch-all/no-arch-all for BUILD_ARCH_ALL and s|source/no-source
for BUILD_SOURCE. Adding an option arch-any/no-arch-any would have
made this problem non existent from the start and at least to me was
the more intuitive way to implement the desired functionality. Then
this would have done it:

--arch-all-only => --arch-all --no-arch-any
--source-only => -s --no-arch-all --no-arch-any

It would still have required the ability to extract the
*_source.changes but that is simpler to fix.

I thought of this before but did not create the patch this way since
--arch-all-only seems to have been deployed to the buildd in
"lib/Buildd/Daemon.pm":

-push ( @sbuild_args, "--arch-all-only" );
+push ( @sbuild_args, "--arch-all" );
+push ( @sbuild_args, "--no-arch-any" );

Doing no-arch-any/arch-any is IMO cleaner than trying hammer the
documentation to fit the current confusing implementation but probably
harder to get merged into git.

Cheers,
Miguel