Re: Seeking feedback on a meta package builder
Hi,
On Wed, 02 Jun 2021, Helmut Grohne wrote:
> * debusine's build milestone implements a lock-in on sbuild. The
> abstraction that I'm seeking doesn't happen here.
Just to be clear, I think I want that kind of abstraction at some point.
Because one should be able to schedule a package build and it should be
able to build without preference on a worker where we have sbuild + the
appropriate chroot or on a machine where pbuilder has been setup or
on a machine with mdbp ;-)
But Freexian is paying someone to get this code so I'm doing it with small
steps that lead to a minimal viable product on which we can cooperate
further. Release early, release often. :-)
That abstraction will likely come later when someone implements a second
way to build packages.
> Possibly debusine could replace its sbuild task with a mdbp task?
I don't intend to restrict too much the number of "tasks" that I will
accept in debusine, we can have both if it makes sense. Though I believe
that this is an abstraction worth having at the debusine level without
delegating that abstraction to "mdbp".
> would automatically work on pbuilder and mmdebstrap for free. It also
> doesn't have to implement another method for issuing builds remotely and
> can concentrate on the scheduling part.
That's not really relevant, part of the goal of debusine is to let
you leverage a network of workers for any kind of task, not only for
package builds.
> > In the current design
> > (https://salsa.debian.org/freexian-team/debusine/-/issues/7) for the
> > current iteration, I don't have that level of details but it should
> > not be too hard to add this on top. Only the differentiated handling of
> > build/host architecture might be non-trivial as it will impact the scheduling
> > (identification of an appopriate worker).
>
> Please get the architecture part right from the start. It is not that
> hard actually. Your issue already mentions an unspecific "architecture"
> field, so you already get to choose suitable workers. It is only the
> build architecture that affects worker choice. The host architecture is
> only a setting to pass down and debusine does not have to care about it
> at all.
I tried to fix it based on your feedback in the ticket but it looks like
it doesn't match your expectation. When I request a build for the "arm64"
architecture, I want "arm64.deb" as output, that's defined by the "host
architecture" right?
(In this context, I would not care if it's build by cross-compilation in
an amd64 build chroot or if it's build natively in an arm64 chroot)
> Maybe we can use some AWS credits to provide PBaaS to developers at some
> point. Or even archive rebuilds as a service.
Definitely.
> While Debian uses sbuild in official buildds, reproducible.d.n is fully
> built on pbuilder instead. It isn't that homogeneous in the end. In
> order to make debusine easier to set up, I think it should not tightly
> couple with sbuild.
As I said, I don't want to tightly couple it, it's just the easiest and
most useful first step for me.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: