Thorsten Glaser wrote: > True, but that would lead to major unnecessary package churn with, > in my case, about 700 MiB (compressed size) per upload. Iâd prefer > to avoid that, for snapshot.d.o sanity and users on poor bandwidth > connections (i.e. Germans) â»
I see. I am one of those stuck with a 12MB DSL line. And that's download speed. :-/ > OK, /usr/share/sounds/sf[23]/default.sf[23] then. Ack. > Oh, interesting. Is there prior art for this? I think it can only > add alternatives for those packages that are actually installed⦠I guess I am wrong. Packages providing the call to update-alternatives in their maintainer script should provide the corresponding virtual package. > ⦠for simplicity, Iâd use this dependency though: > > timgm6mb-soundfont | sf2-soundfont This seems reasonable to me. > OK, good point, although Iâd decrease opl3-soundfont as itâs > special-use > (and whether fluid-soundfont-gs should be included at all?) and put > MuseScore_General (actively developed) over all Fluid ones (frozen). Agreed. > The sf3 ones can also fulfill sf2. Isn't it the other way round? I mean, not every application that can render SF2 soundfonts can also render the SF3 variant. > Does this look agreeable? Did I miss any (I did a search for > packages with âsoundfontâ in their name)? Did I misidentify > any non-SF2 ones as SF2? Absolutely. > Sure. Some people consider GS sufficient for MIDI, some donât, it > really depends on what kind of music to play. Just leave out > fluid-soundfont-gs and start with timgm6mb-soundfont at 20 > if we do that. Easier to change later. Agreed, let's leave out GS soundfonts and priorize the OPL font below TimGM6MB. > Changing the alternative might be easier and robuster. For sure. > Ouch, donât do that⦠Possible, though not recommended . ;-) Cheers, - Fabian
