Re: Seeking feedback on a meta package builder
Hi Raphaël,
On Fri, Jun 04, 2021 at 08:42:23AM +0200, Raphael Hertzog wrote:
> 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".
This is very sad. The whole point of me reaching out where was
specifically trying to avoid this kind of fragmentation and now you're
adding to it. While mdbp also is an implementation, it first and
foremost is an API and I'd hope that it would be generic enough to be
reused here. Long term, I'd hope that each build tool would provide
their own implementation of the mdbp API, but adding multiple competing
build abstraction APIs is not going to get us there. Build tool authors
will rightly refuse saying that people should agree on an API first.
Choice is nice, but fragmentation has a cost.
Of course, you can turn this around and say that I'm the one fragmenting
and I should be using the debusine abstraction. Unfortunately, I'd need
a time machine to get it from the future. Otherwise, I'd really do that.
> 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?
Correct.
> (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)
A different way to put this is to say that the build architecture does
not matter and is left unspecified.
> As I said, I don't want to tightly couple it, it's just the easiest and
> most useful first step for me.
I doubt this is true. You already learned the hard way that coming up
with an abstraction for just sbuild is difficult. Using an existing
abstraction saves you from a pile of thinking and quite certainly is
easier.
Helmut
Reply to: