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
