[DRE-maint] Bug#882163: ruby-ronn: unable to satisfy cross Build-Depends

[Simon McVittie]

On Sun, 19 Nov 2017 at 20:25:52 +0100, Helmut Grohne wrote:
> That puts us in a difficult spot: We must mark it and we cannot. Looking
> closer, libidn2 really needs /usr/bin/ronn, not the ruby module. A
> package containing just the script could be marked. Thus I propose
> splitting ruby-ronn into another binary package "ronn" containing
> /usr/bin/ronn. This new package could be marked Multi-Arch: foreign and
> thus solve the issue around libidn2.
> 
> Introducing this new package is not trivial: It must go through the NEW
> queue and we need to review the other 35 source packages that depend on
> ruby-ronn and maybe switch their dependency over to ronn. Still this
> solution sounds manageable to me.

This mirrors what Policy would require for C libraries that are
accompanied by executables, and what at least some people in the Python
teams consider to be best-practice for Python libraries that are
accompanied by executables:
https://wiki.debian.org/Python/LibraryStyleGuide#Executables_and_library_packages

(tappy from src:tap.py is an example of following that pattern with
Python.)

If ronn had been written in Python or Perl rather than Ruby, bundling
/usr/bin/ronn in python-ronn, python3-ronn or libtext-ronn-perl would
have had the same bug. I would personally be inclined to say that all
the interpreted languages should move towards a policy where the library
package only contains the library, and any accompanying executables should
usually be packaged separately - particularly if those executables might
be the subject of (build-)dependencies.

    smcv