[buildd-tools-devel] why is sbuilds BUILD_DIR option deprecated?

[Roger Leigh]

On 02/11/2015 14:53, Johannes Schauer wrote:
> Hi,
>
> the man page of sbuild.conf says:
>
>   BUILD_DIR
>       STRING type. This option is deprecated. Directory for chroot symlinks and
>       sbuild logs. Defaults to the current directory if unspecified. It is used
>       as the location of chroot symlinks (obsolete) and for current build log
>       symlinks and some build logs. [...]
>
> Why is this option deprecated?

I deprecated it because at the time, it seemed like the right choice, 
but undeprecating it is totally fine if you think it makes sense.

Originally, sbuild didn't use the current working directory for anything 
and it required a hardcoded directory IIRC ~/build or similar.  We made 
it configurable and then later we defaulted to the current working 
directory.  The goal was to make sbuild equivalent to invoking 
dpkg-buildpackage, but doing the build in a virtual environment.

That's the rationale for the default behaviour, anyway.

> I found it very useful to tell sbuild to put all its output into a new
> directory so that I can easily clean up after an sbuild run.
>
> Or is a script calling sbuild with a dsc expected to first cd into the
> directory where the script expects the output before executing sbuild?

This is a good question, and it really depends upon how you want sbuild 
to behave.  dpkg-buildpackage requires you to run it in the source tree, 
and places the build products in "..".  sbuild will also work in the 
same way when run in a source tree.  When invoked with a .dsc we have 
the choice of placing the build products in the same place as the .dsc 
or to place them in the CWD or somewhere else entirely.  I think the 
same place as the .dsc is incorrect; it might be read-only or owned by 
someone else, or it might overwrite previous builds (example: building 
from local mirror).  The CWD is reasonable, as is placing it in a 
specific location.

> So instead I'm actually inclined to expose this option as a command line switch
> because it's tedious to pass this option as a custom sbuildrc which is then
> passed to sbuild using the SBUILD_CONF environment variable.

Sounds fine as a command-line switch (along with un-deprecating the 
config file option as well I would presume?).  I think the current 
behaviour is reasonable as the default, but having this as an option 
sounds useful.


Regards,
Roger