Re: Seeking feedback on a meta package builder
Hi,
On Mon, 07 Jun 2021, Helmut Grohne wrote:
> My abstraction says nothing about workers or how to select them. The
> idea behind that was that a user should not have to care. Yes, you
> (debusine) do need a mapping between workers and available distributions
> somewhere. You can implement scheduler as a middleware (or router) in
> the abstraction I'm proposing to do this selection. What I don't see is
> where this hurts. The worker selection is something that you have to do
> anyway regardless of whether you use mdbp for the build abstraction.
The point is that if you have to look behind the abstraction to do some
other related tasks like selecting the worker, then using the abstraction
to actually execute the build doesn't bring you much, just supplementary
issues if the assumptions that you make no longer match the assumptions
implemented in the abstraction.
And it seems to me that aiming for "it works out of the box without having
to configure mdbp (if you already have sbuild schroot or pbuilder
tarball)" is a nice thing to aim for. So somehow it would be nice if your
various mdbp-* implementations could report whether they are able to
perform a given build.
It would not be enough for debusine yet (for debusine I need to be able to
export data from the worker and then make that decision on the server and
not on the build machine itself) but it would be nice step forward for the
local use case where you want "mdbp" to figure out alone which backend to
use based on what the user did setup earlier.
That said if you are willing to complexify your mdbp abstraction to
cover this use case, then there might be room to actually use mdbp in
debusine. I would still be annoyed by having to interface with CLI calls
to make basic requests like those and I would hope that we could define a
Python API instead.
> I'm actually interested in figuring this out as the fewer competing
> abstractions we end up with, the better they will be supported.
Sure.
> I note that my abstraction kinda has two levels. For one thing there is
> a build object (represented as json, but that really doesn't matter). It
> describes the action that is requested by the user (what to build,
> architectures, options, etc.).
This abstraction definitely makes sense to me. Before looking closely
at your build_schema.json, but after having looked at your mail here,
I wrote this as a try to go in your direction:
https://freexian-team.pages.debian.net/debusine/devel/ontology.html#task-packagebuild
There are some differences that we should strive to eliminate but I leave
that up to you to comment, it's too late for me right now. :-)
Feel free to submit merge requests to update my document to more
closely match yours (many entries are missing).
> The other is a command line interface that receives a build object and
> transmits (via files) the relevant artifacts. Maybe the build object
> level better addresses the needs of debusine while leaving some aspects
> unanswered (e.g. artifact transmission).
Yes, the "command line interface" does not really help for debusine,
unless you extend it to cover the requirements I explained above. And even
then I don't really like to have to run an external executable to be able
to answer a question like "can this worker handle this build request".
On the opposite, the fact that debusine will expose a "PackageBuild" task
matching your abstraction means that it will be trivial to write
mdbp-debusine.
Cheers,
PS: I already hate the "mdbp" name after having it typed so many times.
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: