Hi Simon, On 12-09-2026 01:12, Simon Richter wrote:
-> build big and little endian database packages that are arch:all.This is easy enough to do, and adjusting the dependencies of the binary packages is also doable.However, the included unit tests depend on these databases being available, which leaves two options:-> declare Build-Depends-Arch on the database.This should work for Debian, because arch:all is a separate autobuilder, but it feels kind of unclean.
Does this need to have strict versioned constraints in either direction arch->all or all->arch? That would probably make it fragile. If (usually) both can be built with an old version of the other, than I think it's probably fine (I might be overlooking something of course).
It is also difficult to declare a dependency on the correct endianness of the package, unless I also-> make the packages co-installable (changing internal paths), and depend on both.
After reading this several times I figured that you implied building 2 arch:all binaries, one for le and one for be? Might be good to say so explicitly. What's the problem you see?
I'd also need a mechanism to allow building all binary packages at the same time, obviously that should not depend on the prebuilt database.
Related to my question above: would a previous version of the database work? Than I don't see a problem. You'd want to have different build time tests for the arch:all build (are the databases OK) than in the arch:$arch build (does the binary work correctly with the (current or old) database). So it probably requires logic already. (By the way, how are you going to test the be database on our arch:all builders?)
This feels like I should find out if the target invoked was "build" or "build-arch", and, depending on that, decide whether to build databases or just use them. That doesn't feel clean at all either.
So, during testing use the database if it's built and use the as-installed database if it's missing? I mean don't we first build the source and *then* run the tests, right?
-> Alternatively, I could ship unit tests as a package, run through CI.
You can also (even additional to build time tests) build the unit tests (please don't build the full source) in CI and run those, if they test as-installed binaries.
This pollutes the package namespace, and reduces test coverage to architectures covered by CI.
All release architectures are covered by CI (to be precise, currently not s390x, but that's not normal).
Either of these also means that we no longer test whether the package can be completely built on all architectures, but I suppose that is minor.
Do you mean with "completely built" "completely built and run the build time tests"? Because you need a complete build to ship binaries, right? Or do you mean that you don't know if you can build the database on all architectures (because our arch:all builders are currently always amd64?) The later is indeed an minor issue, bugs are filed if somebody runs into this and I recall some QA efforts try to tests at least once per release cycle on e.g. arm64 and i386. I also think it's wasting maintainer time if they are trying to keep memory hungry arch:all builds feasible on our 32 bits architectures only for that sake. (Addressing memory consumption in general is an effort sometimes worth doing, that's not my point.)
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
