Hi Andre, On Sun, Aug 18, 2024 at 07:32:01PM +0200, Andre Noll wrote: > So the problem is that to cross-build tfortune we'd need lopsubgen > for the build architecture and liblopsub for the host architecture, > but this is currently not possible since the two belong to the same > package, and this package cannot be installed for two different > architectures at the same time. Correct?
I agree with all detail. > > I am proposing to split the liblopsub-dev package into a liblopsub-bin > > package. Since the former depends on the latter, all existing uses will > > continue to work as is. Things change when we attempt to cross build. > > liblopsub-dev will continue to be installed for the host architecture. > > liblopsub-bin will be installed for the build architecture though as it > > will be marked Multi-Arch: foreign. That enables us to actually run > > lopsubgen. > > I have to admit that I'm having trouble understanding what exactly > Multi-Arch: foreign means. The debian wiki^[1] says > > The package in question is Architecture: all, does not contain > any maintainer scripts and does not have any dependencies on > architecture-dependent packages. What you are reading here is not a description of Multi-Arch: foreign, but a particular situation in which the automatic hinting suggests the addition of Multi-Arch: foreign. In other words, this is one of multiple sufficient, but not necessary condition. Multi-Arch: foreign is difficult to grasp. I actually tried describing it in policy-like language at https://wiki.debian.org/DependencyHell#Multi-Arch:_foreign with limited success. I propose the executive summary: | A real binary package may be marked with a Multi-Arch: foreign control | header if the provided interfaces are independent of the architecture of | the package. The tricky part here is deciding what contributes to the "provided interfaces" of a package. > I guess this is true for the proposed liblopsub-bin since it will > only contain the lopsubgen executable and its man page. It will still > depend on libc, though, which *is* architecture-dependent just like > any shared library. Practically speaking, the question to ask here is when you have two lopsubgen executables on two computers of different architectures, will you be able to tell the architecture apart by interacting with lopsubgen in intended ways? > Yes, both the input format and all three output formats of lopsubgen > (.c, .h and roff) are architecture-independent. I imply an answer to my previous question of "no" from this answer. > > The proposed change requires a trip through the NEW queue as it > > introduces a new binary package. It's not a trivial change nor easily > > reverted (as it requires reverse Breaks+Replaces to revert). > > This I don't get. Why couldn't the change simply be reverted and the > version number be bumped again? We are moving files between packages. A user may have liblopsub-bin installed. If you were to just revert the changes, a new liblopsub-dev were to include lopsubgen and liblopsub-bin might still remain on a user's system without any new version appearing. On the next upgrade, there would be an undeclared file conflict between the last liblopsub-bin and the reverted liblopsub-dev. Your revert needs Breaks+Replaces. Not a huge deal, but something to keep in mind. > > Please take a bit of time to understand the proposed change before > > committing > > it and ask any questions you may have. The lib*-bin split is quite common > > and > > in searching for similarly named packages you shall find a number of prior > > art examples. > > My main question is how one can test such a change without uploading > the modified version first. You can locally build liblopsub for two architectures (e.g. amd64 and i386). Unfortunately, liblopsub cannot presently be cross built itself (see below). Then you may try installing liblopsub-bin:i386 on an amd64 system and see whether this combination allows natively building tfortune. This is not a cross build, but it reversely exercises the multiarch capabilities. You may also just upload to experimental. Then you can try your change there and since upgrading from experimental to unstable is not generally supported, you may just revert it (without Breaks+Replaces) in case it does not work out. Once uploaded, you may try cross building tfortune against the experimental liblopsub. > Another question concerns the lopsubgen-stage1 executable, which is > built and run to bootstrap the package, and should thus be built for > the build architecture. However, this is not the case as the Makefile > is not cross-compile aware. Is this going to cause problems? There are two vaguely orthogonal issues to consider here. One is laying out the liblopsub in such a way that it better supports cross building of other packages (this bug) and the other is cross building liblopsub (not a filed bug). What you are describing here is an aspect of the latter problem. In order to solve that, the upstream Makefile should have two distinct variables for the C compiler. The most common naming is "CC" (for the host compiler) and "CC_FOR_BUILD" (for the build compiler). Then, lopsubgen-stage1 should use CC_FOR_BUILD, but it also needs a separate set of object files or alternatively combing compiling and linking to avoid the need for build architecture .o files that could conflict with the host architecture ones. /usr/share/dpkg/buildtools.mk can be used to compute the correct values for these variables. You may cross build packages using sbuild by adding --host=somearch or using pbuilder by adding --host-arch=somearch. In case this leaves questions, continue asking and thanks for considering my change. I can also sponsor an upload if that helps. Helmut
