[buildd-tools-devel] [GIT] sbuild branch master updated. debian/sbuild-0.65.2-1-22-g6d705b3

[Roger Leigh]

On 13/09/2015 11:55, Johannes Schauer wrote:
> Hi,
>
> Quoting Aurelien Jarno (2015-09-06 19:59:07)
>> On 2015-08-31 12:05, Johannes Schauer wrote:
>>> I saw that it does not seem to be customary to update debian/changelog
>>> along with any commit that warrants mentioning there. To keep track of the
>>> bugs that were closed, I mentioned them in my commit messages.
>>
>> I don't know if it is a good idea or not. I think it's done to ease
>> cherry-picking patches between branches.
>
> yes, that makes sense.
>
> I also wonder about the distinction between the sbuild Debian packaging and the
> "upstream" part of it.
>
> Is sbuild intended for Debian only? Then why is it not a native package?

The main reason is that "native" packaging is somewhat inflexible. 
Having an upstream release allows for multiple Debian releases, 
including on the separate buildd branch, backports etc. without this 
needing to be part of the main version.  And there are downstream and 
external users of sbuild who do modify it to suit their purposes.

> If it is not, then why is the debian directory part of the upstream git (and
> not at least in a separate branch)? In that case, a new upstream release would
> also just say in d/changelog:
>
>   - new upstream release (Closes: #11111, #22222, #33333, ...)
>
> Instead of mostly being a verbatim copy of the git commit messages between now
> and the last release (which is something I'd expect from a native package).
>
> So right now it looks like a weird mixture to me. How is this intended to be
> handled?

It's mainly this way for historical reasons--it was native before I 
started doing more formal upstream releases to ease use of the different 
git branches (buildd, backports).  If you want to revert to native you 
could do so.  If you wanted to do a pure "upstream" release with the 
debian packaging on a separate branch that's also reasonable. 
Personally, I think there is some value in having the discipline and 
formalism of going through the testing and validation of a release, but 
if there is value in changing it then certainly don't let this stop you.

>>> Please comment in the respective bugs if you find my solution to be
>>> unsatisfactory (maybe CC me directly just to make sure).
>>>
>>> Please reply here for general comments about contributing to sbuild. As this is
>>> my first push, I might've made some mistakes.
>>
>> I just gave a quick look to all the patches. I haven't looked at them in
>> details, but I have rather looked at what they are doing. I think they
>> are fine overall, but I have a few comments:
>>
>> - d720bb7a: add --build-path option: The default fstab in sbuild and
>>    buildd mode, /build is actually from /var/lib/sbuild/build and it is
>>    customary to mount a big partition there as build space. I don't know
>>    how we should handle that with --build-path, maybe at least emit a
>>    warning when this option is used while /build is mounted by the
>>    schroot fstab?
>>
>>    For the official debian build daemons, we don't use a separate
>>    partition (we have a fstab different from the default one) so that
>>    should not be a problem.
>
> Is bind-mounting /var/lib/sbuild/build to /build inside the schroot useful for
> any purpose these days? If the user wants to use a big extra partition for
> scratch space, then would they not mount that partition to
> /var/lib/schroot/unpack/ so that the whole chroot sits on that separate drive
> or partition?

The main reason is to decouple the lifetime of the build directory from 
the lifetime of the chroot.  This is so you can preserve the build 
directory for debugging purposes.  While space is certainly part of the 
equation--originally stemming from LVM snapshot space restrictions--it's 
not the whole picture.  While any storage may be mounted here (or not), 
please do account for persistence of the build in the configuration.

sbuild can also preserve the schroot session, which would preserve the 
build directory for the case of file chroots, but that's really a 
separate option for if you need to re-enter the build environment, check 
and test with the installed build-deps etc.

> Would anything break if /var/lib/sbuild/build was not bind mounted to /build
> inside the schroot in the default schroot configuration anymore? Users who
> really do want sbuild to utilize a separately mounted device should use
> /var/lib/schroot/unpack/ anyways in the first place, no?

Nothing should break the build, but you will lose preservation of the 
build directory.

> As I see it, bind mounting all the possible (because of access rights) build
> locations like /tmp, /build or /home in the schroot is mutually exclusive with
> reproducible build paths. Because then it is not possible to do two builds of
> the same source package in parallel because the build paths will be the same.

For the most part these should be independent.  There's no need to bind 
/tmp or /home.  /build is for a separate purpose and is orthogonal to 
reproducible builds--the paths you use under this location can be fixed 
or random as you see fit.  But if it makes it easier for reproducible 
builds to omit it, you can, but please bear in mind the non-reproducible 
cases for debugging and investigative purposes.



Regards,
Roger