On 06.06.19 20:08, Helmut Grohne wrote: > 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?
I would go for the "cleaner" solution A. It matches what it is done with flex. And it matches with yet another autotools related tool: libtool. libtool also doesn't have an explicit dependency on libltdl-dev. Matthias
