Package: autogen Version: 1:5.18.16-6 User: [email protected] Usertags: ftcbfs Control: affects -1 + src:complexity X-Debbugs-Cc: [email protected]
Hi Andreas, the removal of Multi-Arch: foreign breaks cross building complexity. This is not asking you to just put it back. The reasons for removing it are sound. This is reporting the failure and looking for better solutions. One of the primary reasons for turning dropping M-A:foreign is its .pc file being located on an arch-dependent path. Fundamentally, that .pc file should not reside in a package marked Multi-Arch: foreign and one way to get there indeed is removing Multi-Arch: foreign from the package. Another way of looking at this is saying that autogen.pc should not reside in the autogen binary package. The right place to locate this file is difficult, because it describes both /usr/bin/autogen as contained in autogen and libopts.a contained lib libopts25-dev. Arguably, neither place is fully correct. While looking at this, I observe that libopts25-dev does not depend on autogen and therefore discovering libopts.a using pkgconf does not work reliably by issuing a dependency on libopts25-dev. Mayb autogen.pc should rather be contained in libopts25-dev? Let me also provide some wider context. autogen is not the only package that combines a library with a tool. Other examples include flex (libfl-dev) and bison (libbison-dev). There are two main ways of approaching this problem. The way chosen by bison and flex (and vaguely also autogen) is to have client packages depend on *both* the tool and the library (though libfl-dev Depends on flex). This tends to be error prone as it regularly happens that client packages forget to depend on the library. Not all client packages do use those libraries and there are a number of users that actually need the tool only, so that extra dependency actually is beneficial. The other way of approaching this is turning things around. The main package name (autogen in this case) can install the library (what now is libopts25-dev) and also depend on the package containing tool (what now is autogen). The tool package would become an implementation detail and users should never depend on that directly and always go via the main package name. As such, installing autogen would still provide /usr/bin/autogen, but the way it does is by depending on another package that actually contains it rather than installing it itself. This latter approach is beneficial if you expect that all users of the package need the libopts.a library. I suggest that the restructuring discussed here is inappropriate for trixie and that it be considered for forky instead. Meanwhile, I agree that technically speaking M-A:foreign is wrong, but practically speaking dropping it breaks stuff that used to work, so maybe issuing a subtly wrong M-A:foreign for trixie is the lesser evil. Please let me know what you think. I'm happy to work on patches both for trixie and for forky. Helmut
