Re: Seeking feedback on a meta package builder
Hi Raphaël,
On Thu, Jun 10, 2021 at 03:00:31PM +0200, Raphael Hertzog wrote:
> I want to know it precisely in the context of selecting a worker. I don't
> want to schedule a task on a worker and later get back an answer "sorry I
> can't handle your task", and then have to schedule it on some other
> worker.
I'm a little unsure what you mean precisely here. Do you want your
scheduler call out to your worker and ask it whether it can handle the
build? Or do you want to locally decide whether your worker can handle
it (e.g. using data previously acquired from the worker and cached on
the scheduler)? Or do you want to know whether a backend is capable of
satisfying a request in principle without considering the concrete
system performing the build?
I guess it is not the last variant, because you cannot validate the
distribution in any way. I guess it also is not the first variant,
because you don't want to call into every single worker for every single
build object. Do you confirm that you want the second variant?
That might be a little more difficult due to the data collection part.
I'm not sure I can reasonably cover that.
> When I have selected a worker, I want to be sure that the worker
> is properly configured to be able to run that specific task.
That much makes sense in principle, but what do you want debusine to do
when one of your workers is misconfigured and cannot reach its primary
mirror? All builds there will fail and likely you can identify that the
failure happened too early for the package to be at fault. You can
either pass down the failure such that users have to deal with temporary
issues or automatically reschedule the build elsewhere. Additionally,
you can disable such a worker of course. Still, I suggest that you
cannot rule out all possible worker-specific failure modes ahead of
time.
> Yes, but using the ssh backend will require specific user configuration
> while the sbuild/pbuilder one could potientially be auto-selected based
> on whether the user did run the appropriate sbuild-create-chroot or
> pbuilder --create earlier.
That definitely is implementable. It could be a simple "use sbuild if it
works, else try pbuilder, else try mmdebstrap with a default mirror". I
don't think I'd use it, but it might be a good default value for tools
that need to perform builds. I've taken a note and will look into
implementing this.
> "justadeb" or "gimmeadeb" or "buildadeb" because I just want a .deb (and I
> don't care how it gets built!).
Indeed, one of my use cases is to get a log and no .debs. You can
explicitly request no artifacts and that'll prevent them from being
transferred over mdbp-ssh.
> "deblord" or "debring" - the lord of the ring to tie all package builders
> together
Hmm. The more I think about this, the more I like the untypable mdbp:
You only type it once to configure your application that does perform
builds. If you actually type mdbp regularly, you're doing it wrong. It
really is not meant as a frontend to be used interactively.
Helmut
Reply to: