Bug#612509: Why the libwildmidi1 recommends on freepats is bad
bunk at stusta.de
Wed Jun 6 19:59:19 UTC 2012
On Thu, Jun 07, 2012 at 03:20:08AM +0900, Emmet Hikory wrote:
> My apologies for letting this sit: despite my disagreement with the request, it has deserved a more comprehensive response for far too long.
> Adrian Bunk wrote:
> > you are missing the core problem here:
> > wildmidi might not be useful without freepats, but I'd estimate 99% of
> > all people installing libwildmidi1 do not want to use wildmidi at all.
> 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.
> ... 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.
> 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.
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.
>... 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'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.
> Emmet HIKORY
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
More information about the pkg-gstreamer-maintainers