Re: Seeking feedback on a meta package builder
Hi,
On Mon, 31 May 2021, Helmut Grohne wrote:
> I see this tight coupling as a problem for mainly two reasons.
[...]
> * As tasks grow, there is a desire to distribute builds to multiple
> machines. As such, the various tools typically grow their own
> strategy for moving build tasks between machines.
We already exchanged a while ago about "debusine", it ought to solve this
part a least.
https://freexian-team.pages.debian.net/debusine/
We're just starting to work on the project with the goal of handling
package builds as a first step:
https://salsa.debian.org/freexian-team/debusine/-/milestones/1
I invite you to "watch" the project on
https://salsa.debian.org/freexian-team/debusine so that you get
notification of comments on issues as that's where we are discussing
the design.
And feel free to file feature requests.
> So I set out to solve this. More precisely, I looked for an API that
> could abstract both sbuild and pbuilder (because they're the most common
> ones) and allow executing builds on remote machines. A tool performing
> builds should not have to care which one is in use and whether the build
> is performed locally or not. Since describing the settings of a build
> can be complex, I chose json for representation. Some aspects that you
> may want to set for a build are:
> * build architecture / host architecture
> * arch-only / indep-only / full
> * DEB_BUILD_PROFILES
> * DEB_BUILD_OPTIONS
> * whether network access is permissible
> * forcing a build path
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).
> * Does the problem scope I've chosen make sense?
"Package Build as a Service" :-)
When thinking of debusine, I thought something of something similar, I
have set out to use sbuild in the first iteration because that what I
(and Debian) uses for official package builds but given the number of
different ways to build packages, I was wondering whether I should
consider to have a tool-agnostic "PackageBuild" task that can be scheduled
and that could then be performed by tool-specific implementations.
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: