[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#930091: bison is wrongly marked Multi-Arch: foreign



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


Reply to: