reassign 684115 libwildmidi1
tags 684115 -patch
retitle 684115 Please help remove freepats from install CD1
tags 612509 -wontfix
severity 612509 important
retitle 612509 Please avoid the transitive recommends from gst-plugins-bad to
freepats
merge 612509 684115
thanks
In IRC discussion following the filing of (duplicate) 684115, Ansgar
convinced me that addressing the transitive apparent dependency between
gstreamer0.10-plugins-bad and freepats needed to be solved, as other means
to eliminate freepats from CD1 in the install set were unsuccessful. While
I remain convinced that this should not be done by changing the current
Recommends: in libwildmidi-config to Suggests:, there are two means by which
this can be solved. Either the creation of a gstreamer0.10-plugins-wildmidi
binary package or potentially a change from Depends: to Suggests: between
libwildmidi1 and libwildmidi1-config.
This will have the side effect of breaking working MIDI rendering on
web pages for most new users, although those users who expect such things to
work may install the appropriate package where the relationship is broken,
and packages that wish to ensure the functionality can Recommend: the
appropriate package, depending on the point at which the chain is broken.
Current users should be unaffected by either change (and should need to take
manual steps to remove freepats if it is already installed).
From what I understand, it is now too late in the wheezy cycle for a
new package split of gst-plugins-bad0.10, so that this is no longer an
immediately available option (it is also annoying, for various reasons
discussed previously in 612509). Addressing this with the second potential
solution is significantly easier, although it brings the side effect that
users who happen to install timidity *may* end up with working MIDI through
gstreamer and wildmidi, even with libwildmidi-config uninstalled (as a result
of agressive searching for configuration files in the gstreamer code).
Unfortunately, I beleive this also cannot be achieved until after the wheezy
release, as the package split creating libwildmidi-config postdates the
squeeze release, requiring the stricter dependency to guarantee appropriate
file ownership for squeeze->wheezy upgrades (and undoing the package split
both eliminates the opportunity for breaking the transitive dependency this
way and makes libwildmidi1 non-multiarch-compliant).
Having looked through the relevant gstreamer and wildmidi code, I believe
the latter option to be less invasive, as both codebases seem to assume that
the configuration file may be missing or empty and the entire pipeline seems
to exit gracefully when there is no configuration. What testing I have
performed supports this, although if other's testing differs from my results,
I would welcome any patches to help ensure appropriate behaviour in the
unconfigured use case.
If anyone has suggestions on how to achieve this in wheezy without either
telling wildmidi to use a config file that references files not expected to
be installed in parallel (with the default package manager configurations),
or leaving upgrading users in a state which requires actions beyond the
maintainer scripts from which to recover, I would be pleased to hear them.
Otherwise, it is my intent to change the package relationships in jessie such
that libwildmidi1 suggests, rather than depending on libwildmidi-config, and
both wildmidi and libwildmidi-dev Recommend: libwildmidi-config (the former so
that users who install the binary tool will have a working configuration, and
the latter so that any runtime test code that exercises a gstreamer pipeline
will work rather than reporting failure to initialise). Users upgrading from
wheezy should experience no unexpected behaviour changes, freepats should no
longer appear on CD1, and users who prefer not to render MIDI may save some
disk space.
--
Emmet HIKORY
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
