On 2018/01/12 15:47, Brian Callahan wrote:
> Hi ports --
>
> I would like to spin off the GUS patchset we awkwardly bolt onto the
> timidity package into its own package. This is because sdl-mixer and
> sdl2-mixer both have their own internal timidity, and currently timidity is
> not set as an RDEP for either, meaning that both sdl-mixer and sdl2-mixer
> effectively have no out-of-the-box midi support, even though they could if
> only we supplied a default patchset as an RDEP. I don't see a reason to
> include some useless (and old...) binaries to gain that support.
> Additionally, I have another port ready to go (audio/wildmidi) that also
> needs a patchset. Seeing as wildmidi is itself a midi player, it seems
> strange to have to install a different midi player to get wildmidi to work
> out-of-the-box.
>
> I did have to tweak a pair of consumers, games/corsixth and games/openxcom.
> Both use one of the sdl-mixer ports for midi audio, meaning that a useless
> timidity binary has to be installed just to get audio. This changes things
> so that sound works as expected, no extra binaries need to be installed.
> I'll note there is precedent here with sf2 files,
> audio/generaluser-gs-soundfont being one such example. The timgm6mb port
> includes the GUS patchset and the sf2 file the patchset was generated from.
>
> tl;dr
> 1. spin off the TimGM6mb GUS patchset that we awkwardly bolt onto the
> timidity package into its own package
> 2. update all consumers to use this new package
>
> OK?
>
> ~Brian
>
I agree with splitting it.
You have this in timgm6mb:
share/examples/timidity/
share/examples/timidity/timidity.cfg
@sample ${SYSCONFDIR}/timidity.cfg
This conflicts with the existing timidity package so an @conflict
would need to be registered. However it seems a bit odd to
bundle timidity.cfg in timgm6mb rather than timidity in the
first place ..
It might make more sense to have timidity depend on timgm6mb and
include the cfg in timidity's package instead?
