Bug#1105138: autogen: loss of Multi-Arch: foreign breaks cross building of complexity
Package: autogen
Version: 1:5.18.16-6
User: debian-cross@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:complexity
X-Debbugs-Cc: debian-cross@lists.debian.org
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
Reply to: