On Mon, Nov 20, 2017 at 01:23:07AM +0100, Manuel A. Fernandez Montecelo wrote: > > https://anonscm.debian.org/cgit/collab-maint/libvoikko.git/commit/?id=94e7ce125739e59241c04034f5b0615e93c3cc49 > > Please review. Explanations follow.
I don't think that this split makes sense as is. Either you mark the new package M-A:foreign or you shouldn't split. If some other package needs those tools, it certainly wants to execute them. Thus it will need the build architecture version. In build-depends, this can be achieved by annotating with :native or by marking the package M-A:foreign (and the latter is wrong here). Thus rdeps will have to put up with :native and that means you can simply keep them together. So marking the new package M-A:foreign may be an option. I'm not sure whether it is correct. To figure out, someone should check whether the tools *behave* the same on different architectures. If you feed them the same input (input files, command line flags, environment, etc.), will they have the same output? If the answer is "always yes", then M-A:foreign is appropriate. If M-A:foreign ends up being wrong, I'd not split at all, but simply mark the -dev package M-A:no and update the relevant rdeps to use :native. If M-A:foreign ends up being correct, libvoikko-dev should actually depend on the new package. Thus the full interface formerly provided by libvoikko-dev keeps being provided by virtue of the dependency. But the M-A headers will ensure that the library is for the host architecture and the tools are for the build architecture. Consequently, I'd name the package "libvoikko-dev-bin" and describe it as an implementation detail of libvoikko-dev that you shouldn't use directly. > Context: Contrary to the initial assumptions by Helmut, as I understood > them, the binaries are not needed for compilation at all, they are not > pre-processors or similar tools -- they are instead like "examples" or > derived tools of the library, that others can use. It's like if an XML > library provides a parser or coloriser as a tool. I don't know whether they are used, but if they aren't simply leaving them in the -dev package and removing M-A:foreign is a solution. > So my change splits the package to put the libraries (libvoikko-bin, not > -dev-bin as initially suggested), makes -dev recommend it (for possible > r-depends using it, like voikko-fi using the binary programs in rules), > and -dev is marked as "Multi-Arch: same" while -bin one is not marked at > all (implicit "no", IIRC). As Adrian Bunk pointed out, the recommends can be ignored for most practical things. So better make that a full dependency (as explained above). > However, I am not sure if a "M-A: same" recommending/depending on a > "M-A: no" renders the ": same" unusable, please advise (esp. Helmut). Yes, a dependency from a M-A:same package on a M-A:no package makes the M-A:same annotation useless. That's why I say that you should split if and only if the new package becomes M-A:foreign. The "safe" route is removing M-A:foreign without splitting, because the current use of M-A:foreign is clearly wrong and M-A:no pushes the problem onto users. Helmut
