SDL_mixer has a Requires on timidity++-patches which brings in 51MB of samples. OLPC is not using them and they seem to be purely optional, they are manually added as a Requires.
Can we drop this Requires in F-11?
How can we work this package so tha OLPC doesnt use the space, and they dont need to branch it in CVS?
Right off the bat, I question why we're bringing in the samples with the timidity++-patches, that would seem like a good thing to put in a optional sub-package, but I haven't looked at that package, so maybe there's a good reason.
Anyway, I had to go back (fall of '05) to remember why we added a requires on timidity++. It looks like we added it for this reason:
"SDL_mixer needs /etc/timidity.cfg as well as the timidity instruments in order
to play MIDI files.
To reproduce: "playmus /path/to/a/file.mid", results:
Opened audio at 22050 Hz 16 bit stereo, 4096 bytes audio buffer
Couldn't load [...]: /etc/timidity.cfg: No such file or directory
If /etc/timidify.cfg is manually created without installing timidity++, the
error message goes away, but there's still no sound (due to missing
instruments, I gather)."
Let me look into this some more to see if we can find a better solution, since I think this is a pretty worthwhile goal for F11.
Perhaps split it off to a SDL_mixer-midi package that should make it pretty clear to play midi files you need it. but you can use SDL_mixer just fine without midi support. I guess we would need to find what packages need SDL_mixer midi support and make sure they require SDL_mixer-midi so that they continue to work as expected.
The easiest way I can think of to move it to a -midi subpackage with the least pain would be to add a "Provides: SDL_mixer-midi" to the existing spec file and then get all the packages that do depend on the midi functionality to depend on that. Once they all do you then move the midi functionality to the subpackage.
A repo query returns one package that depends on SDL_mixer.
$ repoquery --whatrequires SDL_mixer
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.
More information and reason for this action is here:
(In reply to comment #3)
> The easiest way I can think of to move it to a -midi subpackage with the least
> pain would be to add a "Provides: SDL_mixer-midi" to the existing spec file and
> then get all the packages that do depend on the midi functionality to depend on
> that. Once they all do you then move the midi functionality to the subpackage.
> A repo query returns one package that depends on SDL_mixer.
> $ repoquery --whatrequires SDL_mixer
You probably want to run your query as:
[bpepple@lincoln Desktop]$ repoquery --whatrequires libSDL_mixer-1.2.so.0
> You probably want to run your query as:
> [bpepple@lincoln Desktop]$ repoquery --whatrequires libSDL_mixer-1.2.so.0
Thanks, now what is the best way to determine what depends on the samples?
OK, to move forward with getting this fixed in mainline can someone (I can do the leg work if people are happy for me to do so) add a "Provides: SDL_mixer-midi" line (or whatever name is chosen) to the package so that we can get packages to start depending if they need that functionality before we split it out to the sub package to minimise breakage. Once the the provide is in and updated packages pushed out we can send an email to fedora-devel and file some bugs to get this happening. I would do F-10 and F-9 as well as rawhide so that if maintainers of dependent packages have the same spec across release it makes it easier for them to maintain.
(In reply to comment #7)
> OK, to move forward with getting this fixed in mainline can someone (I can do
> the leg work if people are happy for me to do so) add a "Provides:
> SDL_mixer-midi" line (or whatever name is chosen) to the package so that we can
> get packages to start depending if they need that functionality before we split
> it out to the sub package to minimise breakage. Once the the provide is in and
> updated packages pushed out we can send an email to fedora-devel and file some
> bugs to get this happening. I would do F-10 and F-9 as well as rawhide so that
> if maintainers of dependent packages have the same spec across release it makes
> it easier for them to maintain.
Peter, I'm probably not going to have time to update this until sometime next week, so if you want to go ahead and update the devel branch before then that would be fine with me. I'd prefer not to do this change to our stable branches, though.
Thanks Brian, With OLPC planning on going with F-11 now for the next release the fix in rawhide would be fine :-) I'll probably get to it earlyish this coming weeks. Cheers
Added "Provides: SDL_mixer-midi" to the package and rebuilt. It should show up in rawhide tomorrow. I'll then file bugs against the dependant packages as I get time.
Reprioritizing this, as it impacts OLPC's Fedora-XO effort as well as SugarLabs' Sugar on a Stick project.
I've just gone and re-reviewed this to file sub packages. It seems that I've misinterpreted this a little. Its not that we need a subpackage but rather we need to remove the dep on timidity++-patches/PersonalCopy-Lite-patches and whoever then uses them can depend on them directly.
Given that its a completely separate package I would think that most of the apps that use it would depend on it explicitly anyway rather than depend on the fact that SDL_mixer depends on it. As a result is there any issue with just removing the dep?
repoquery --whatrequires timidity++-patches --enablerepo=rawhide --disablerepo=fedora
Peter, I don't think it should be an issue to remove the dep on timidity++-patches.
Thanks for the update. Fixed in SDL_mixer-1.2.8-12.fc11