On Sun, Aug 18, 21:54, Helmut Grohne wrote: > 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.
I see, that clarifies a lot. > 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. After having read the above link, the concept is much clearer to me. In particular the first list item "The content of a package" answered my question. BTW: There's a typo in the text of the "Implicit and foreign dependencies of a package" item: s/thoug/though. > 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. Right, it should be impossible to tell apart the architecture. This also means your patch can be applied to the debian branch of the lopsub repo. But see below. > > > 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. OK. Let's hope that this will not be needed. > > > 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. I tried that on two debian-12 systems. First I built lopsub with your patch applied on the i386 system, copied over the resulting -bin.deb to the amd64 system, and ran dpkg --add-architecture i386 there. Attempting to install the -bin.deb package fails because liblopsub1t64:i386 is not installed, and trying to install that results in: # dpkg -i liblopsub1t64_1.0.5-1.1_i386.deb dpkg: regarding liblopsub1t64_1.0.5-1.1_i386.deb containing liblopsub1t64:i386: liblopsub1t64:i386 breaks liblopsub1 (<< 1.0.5-1.1) liblopsub1 (version 1.0.3-2) is present and installed. dpkg: error processing archive liblopsub1t64_1.0.5-1.1_i386.deb (--install): installing liblopsub1t64:i386 would break liblopsub1, and deconfiguration is not permitted (--auto-deconfigure might help) Errors were encountered while processing: liblopsub1t64_1.0.5-1.1_i386.deb Any hints? > 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. Good to know. But this is more complicated since I'd always need somebody to sponsor the upload. > > 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. Then let's focus on the split/layout for now, and postpone the cross building issue until this bug has been fixed. > In case this leaves questions, continue asking and thanks for > considering my change. I can also sponsor an upload if that helps. Thanks for offering your help. That's greatly appreciated. Andre -- Max Planck Institute for Biology Max-Planck-Ring 5, 72076 Tübingen, Germany. Phone: (+49) 7071 601 829 http://people.tuebingen.mpg.de/maan/
