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 <hert...@debian.org> ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
