Package: bison
Version: 2:3.3.2.dfsg-1
Severity: important
bison is marked Multi-Arch: foreign and Depends on libbison-dev.
Packages Build-Depend on bison and expect a libbison-dev (for the host
architecture). This is broken.
We had this problem earlier with flex and I can provide the same options
to fix it.
A. Depend on libbison-dev explicitly. We consider that a dependency on
bison does not include libbison-dev. Not every user of bison needs
libbison-dev and only those that do need it, need the dependency.
This change is quite simple: Drop the libbison-dev dependency from
bison. It makes a pile of packages FTBFS until they add the
dependency. bison has around 540 build-rdeps. I haven't examined how
many need libbison-dev. flex went this way.
B. Reverse dependencies. This is the "tricky multiarch fix". It may take
a while to understand, but we can fix the whole issue with a single
upload of bison:
* Drop the dependency on libbison-dev from bison.
* Rename bison to bison-bin.
* Update the description of bison-bin (formerly bison) to explain
that this package is an implementation detail and people should
continue depending on bison.
* Rename libbison-dev to bison.
* Make the new bison (former libbison-dev) depend on bison-bin
(formerly bison).
* Add Provides: libbison-dev to the new bison (formerly
libbison-dev).
After performing these changes, a Build-Depends: bison will result in
the build architecture bison executable together with the host
architecture liby.a. Things will just work without any need for
modifying downstream packages. People won't have to be aware of the
distinction between the library and the code generator.
Comparing these approaches I see the following trade-offs:
* A makes a ton of packages FTBFS and will need possibly hundreds of
uploads.
* A is consistent with flex.
* A is slightly better for cross building. Given the experience with
flex, I expect that the majority of rdeps won't need libbison-dev.
For cross building this means that bison doesn't have to be available
for the host architecture.
We need a decision on which approach to take. Preferrably soon. I'm
happy to implement either. I'm also happy to take care of the MBF if we
opt for A. This bug should not be fixed for buster. If you ask me, I'd
slightly preferred option B, but since flex did A, I favour consistency
and thus A. What is your (maintainer) preference? Do we need to know how
many packages would ftbfs before deciding?
Helmut
