Bug#612509: Why the libwildmidi1 recommends on freepats is bad

[Emmet Hikory]

Adrian Bunk wrote:
> On Thu, Jun 07, 2012 at 03:20:08AM +0900, Emmet Hikory wrote:
> >     I'd be surprised if even 1% of folk with libwildmidi1 installed have ever heard of the wildmidi GUI interface, let alone have any intention of ever using it.  I've nothing against the interface, but the single most common reason that libwildmidi1 is installed is as a handler for audio/midi, which is nearly always with the gstreamer libwildmidi interface. ...
> 
> No, the single most common reason that libwildmidi1 is installed is due 
> to the dependency of gstreamer0.10-plugins-bad, without the user ever
> intending to do anything with MIDI at all.

    We're saying the same thing here, only differently.
gstreamer0.10-plugins-bad depends upon libwildmidi purely in order to be
able to claim that it provides a handler for audio/midi.  Whether any
given user happened to want to support audio/midi at the time of install
is unknown.

> > ... I believe freepats to be the smallest package in the archive that 
> can meet this requirement ...
> 
> And this is therefore irrelevant, since most people who get libwildmidi1 
> installed do not intend to do anything MIDI related at all.

    Except that we'd be lying to the user if we configure their MIME
handlers to claim there is a handler for audio/midi and then make it not
actually generate audio.  To maintain consistency between capability claims
and service provision, we need to provide something to fulfill this function.

> >     To make an analogy to another library that converts codepoints into something that humans can sense directly, let's consider libpango, which Depends on fontconfig, which Depends on fontconfig-config, which Depends on an arbitrary disjunctive set of truetype fonts.  I'm fairly sure that everyone would agree that installing pango without installing any fonts is a highly unusual use case, but conversely, I can imagine there exists at least one user who has an installed font set from which they would like to purge all of the packages representing the disjunctive set of fonts depended upon by fontconfig-config.  Further, there may even be a user who would prefer to use only out-of-archive fonts. ...
> 
> You have a very valid point that Debian is not designed to offer maximum 
> configurability for every theoretically usecase - there are other 
> distributions that are better for such purposes.

    The point isn't about the configurability of Debian, but rather that
software designed to change machine-comprehensible code into some
representation that a human can sense requires the availability of mapping
between the two states, and that in Debian it is typical to configure for
the working use case, expecting those with uncommon needs to take advantage
of one of the many ways to adjust the package system in order to more
closely match their goals.  My claim is that from the viewpoint of the
libwildmidi-config package, it is an uncommon case that a user wants to
have configuration for libraries to generate audio from MIDI *and* have
those libraries configured to be unable to generate audio.  From a wider
viewpoint, it could potentially be considered uncommon to want to generate
audio from MIDI, but in that case, I don't understand why one would want
to install libwildmidi at all (yes, there is a dependency chain, but that
is just as open to modification elsewhere as in the wildmidi source package).

> But there is a difference between an exotic usecase with a dependency on 
> smaller packages and a very common usecase where a 33MB package that the
> user is unlikely to ever use gets pulled in.

    My issue is not whether wildmidi should be installed for the use cases
you describe, but rather that I find the idea of installing something known
not to perform the described function with the supplied configuration worse
than not installing it at all.  To put this differently, if it is the case
that having a handler for audio/midi is an exotic use case, then the correct
thing to do is not install such a handler, rather than cripple the hander
that is being installed.

> >...
> >... which would mean pulling libgstwildmidi out of gstreamer0.10-plugins-bad and putting it somewhere else ...
> >...
> 
> Splitting gstreamer0.10-plugins-bad into 89 packages for letting every
> application pick exactly the plugins it wants to get installed will 
> likely lead to more chaos than anything else.
> 
> OTOH, if that's the only option I hope the GStreamer maintainers (Cc'ed) 
> will split the plugin out similar to gstreamer0.10-gconf.

    I'm not suggesting that *every* plugin be split out, rather that if
30MB of dependency is considered overly large, that the single plugin that
requires this be split out.  Shipping a less-complete gstreamer-plugins-bad
with the ability to install a separate handler for audio/midi is likely to
be less confusing to users, less complicated as part of troubleshooting issues,
and less opaquely broken than shipping libwildmidi without freepats or some
substitute.

> >... I'd much rather just have the audio/MIDI handler installed by default, since ending the long series of bugs complaining about how browser X, file manager Y, audio player Z, and subsystem G were unable to render audio/midi was my primary motivation to package wildmidi in the first place, but as those bugs are nigh invariably filed on other packages (the concerned users having never heard of wildmidi), and it is up to those other packages whether they want to have a dependency chain that installs libwildmidi, I'm willing to leave that decision to those who maintain those packages, and therefore receive those bug reports (which become support requests, given the availability of a working libwildmidi).
> >...
> 
> The problem with your argument is the semi-randomness that
> "browser X, file manager Y, audio player Z, and subsystem G"
> (none of these might depend on gstreamer0.10-plugins-bad) might
> suddenly be able to handle audio/MIDI after the user installed
> ICQ client Q that depends on gstreamer0.10-plugins-bad.

    Well, except that gstreamer is the preferred backend for media processing
for most desktop users (either directly, or through phonon-gstreamer), and
gstreamer-plugins-bad claims such MIME support.  While there may be browsers,
file managers, or audio players that do not use MIME descriptions for media,
or do not use the common MIME subsystem to identify handlers for such media,
these are less common than those that do.  I doubt that any of the programs
depend on gstreamer-plugins-bad directly, but I do expect that if the user
does install gstreamer-plugins-bad, nautilus, epiphany, and totem will then
begin to handle audio/midi using gstreamer, to pick an example set of
software.  My assertion is that it would be inappropriate for this to not
work because Debian ships a broken configuration, but acceptable (but not
preferred) for this to not work because the user needed to manually install
a theoretical gstreamer-wildmidi package.  As previously mentioned, I'd
expect the "MIDI doesn't work" bugs to return, but they are more soluable
than they were previously (simply tell the user to install the MIDI support
package).

-- 
Emmet HIKORY