On Fri, Aug 16, 19:28, Helmut Grohne wrote:
> thanks for having improved cross building on the tfortune side.
> Unfortunately, it still doesn't cross. This time around, the problem is
> to be found in liblopsub though. In order to build tfortune, we need the
> liblopsub shared library (for the host architecture) and we also need to
> run lopsubgen (as a build architecture executable). These things
> currently reside in the same binary package, but for a cross build we
> need them to be installed for different architectures.
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 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.
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.
> We also need a quick excursion into that Multi-Arch: foreign aspect.
> That stanza is a strong assertion on how a package behaves. In essence,
> it says that the architecture of the package does not matter for
> interactions with it. Quite obviously the architecture of the shared
> library matters and therefore liblopsub-dev must never be marked
> Multi-Arch: foreign. For lopsubgen, we are in a convenient situation.
> All formats that it deals with are textual (e.g. C source code as output
> format). Textual formats typically are architecture-independent. I
> expect that no matter whether I run a amd64 lopsubgen or an armhf one
> (on a suitable CPU or using qemu), it produces the same output. Please
> correct me if I'm wrong and in that case do not apply my patch.
Yes, both the input format and all three output formats of lopsubgen
(.c, .h and roff) are architecture-independent.
> 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?
> 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.
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?
Thanks for spending time to improve tfortune and lopsub.
Andre
[1] https://wiki.debian.org/MultiArch/Hints
--
Max Planck Institute for Biology
Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829
http://people.tuebingen.mpg.de/maan/
