[buildd-tools-devel] Bug#859867: Bug#859867: Bug#859867: Please add a package which automatically configures sbuild for Debian packaging

[Michael Stapelberg]

On Mon, Jul 31, 2017 at 4:24 PM, Johannes Schauer <josch at debian.org> wrote:

> Quoting Michael Stapelberg (2017-07-31 14:19:16)
> > Unless I’m mistaken, the following is what we’d need to recommend to new
> > users:
> >
> > % sudo apt install sbuild apt-cacher-ng lintian
>
> Why install lintian?
>

So that it is available to be used, as per the changed default?


>
> > % sudo adduser --quiet -- "$USER" sbuild
>
> Better:
>
> sudo sbuild-adduser $USER
>

sbuild-adduser gives instructions which don’t apply in our case (AFAIR).


>
> > % sudo sbuild-createchroot \
> >   --command-prefix=eatmydata \
> >   --include=eatmydata \
> >   --alias=UNRELEASED \
> >   --alias=sid \
> >   unstable \
> >   /srv/chroot/unstable-amd64-sbuild \
> >   http://localhost:3142/deb.debian.org/debian
>
> That is *if* the machine of the user is amd64.
>

Substitute $(dpkg --print-architecture).


>
> Also, this part would be Debian-specific. Downstream distributions would
> have
> to adapt the alias and mirror values.
>

Yes.


>
> Also, didn't you also propose to make the schroot be run in a tmpfs the
> default? In that case, eatmydata would be quite pointless, no?
>

I proposed suggesting to build in tmpfs, not doing it by default. If you
think people in general have enough RAM for that to be a good idea, I’ll
happily change it and get rid of eatmydata.


>
> > % echo 15 */6 * * * root /usr/share/doc/sbuild/examples/sbuild-update-all
> |
> > sudo tee /etc/cron.d/sbuild-update-all
>
> Every six hours? I find that a bit excessive. This should certainly be
>

This is the first example
from /usr/share/doc/sbuild/examples/sbuild-update-all itself, which I
assumed was a recommendation. We could dial it down to once a day.


> configurable. Not everybody is behind an internet connection which is fast
>

It is configurable, just edit the file afterwards :).


> enough and/or where one doesn't pay per MB.
>

True, but I’d wager most DMs/DDs (the primary target audience of this
endavour) are. We can slap a fat warning on top of the package description
to clarify that we’re operating under the assumption.


>
> > % newgrp sbuild
>
> This would only have an effect on the currently open terminal and would
> have to
> be executed again on every new terminal session until the user *really*
> logs
> out and in again.
>

Yes. We can tell the user about this fact, but running newgrp seems like a
good idea nevertheless.


>
> > That seems quite involved over, say, “apt install sbuild-setup &&
> > sbuild-setup unstable”.
> >
> > Hence, I’d definitely appreciate a script which does all the over having
> to
> > refer to a wiki page and copy&paste long commands.
>
> Except that the sbuild-setup command would need to become quite complex
> because
> it the user has to be able to control:
>
>  - how to setup schroot (overlayfs? tmpfs?)
>

The default.


>  - where to put the chroots
>

The default.


>  - which distribution aliases (distribution specific)
>

sid for Debian. Downstream can change this.


>  - which extra packages to include (like eatmydata)
>

Only eatmydata.


>  - whether this is the first run or not (warn if the script is run for a
> second
>    time)
>  - how often to update the chroots via cron
>

Once a day, change the crontab file if you want to change that.

To summarize: the point of this script is to provide an easy way to get
sbuild for people who don’t care. People who do care about any of these
details should not use it. I think there is significant value in providing
an easy path, if only as a stop-gap until the user gets around to looking
into this subject area in more depth, and creating their own preferred
setup.


>
> And then we have a script with a complexity which is close to where
> sbuild-createchroot already is.
>
> Or are you actually convinced that it is possible to find a set of defaults
> which fits even half the userbase of sbuild?
>
> Since we are down to two mandatory (and two optional) commands after
> running
> "apt install sbuild", I'd argue that a superior solution would be to
> improve
> the documentation of which commands to run for a "typical" setup. I fear
> that
> trying to create a "one-size-fits-all" script can have many unintended
> side-effects (thinking of users behind bad or costly internet, who use
> schroot
> for other purposes, who don't want to install another deamon like
> apt-cacher-ng, who are not building for Debian but for downstreams...).
> I'm not
> convinced that the time that the user would invest to *really* understand
> the
> things that an sbuild-setup script is actually doing would not be better
> spent
> in learning how to use the individual tools.
>

I think the following suggestion takes care of all the concerns you brought
up: Let’s name it sbuild-debian-developer-setup, describe that the goal is
to provide an sbuild setup which can build packages for Debian unstable,
automates maintenance with its daily update cronjob and assumes an
un-metered internet connection.

Does that sound reasonable?

-- 
Best regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/buildd-tools-devel/attachments/20170801/e597d784/attachment.html>