Olivier Crete made media-libs/gstreamer depend unconditionally always on dev-libs/check, while this is only necessary for some plugins with FEATURES=test. Most users don't care and they should NOT be forced this on them suddenly. This is a reminder bug to revert this or fix it through some proper method (for instance making the gstreamer libcheck thing a separated out package if possible, so that individual plugins can depend on that only with USE=test)
I guess we can make it USE-dep again, but that will require moving every gst plugins to EAPI=2 and having media-libs/gstreamer[test?] in there
Or we could simply move to just good, bad, ugly, base, and gstreamer and add USE flags to them and this bug would be really easy to solve. Removing myself from CC because gstreamer is packaged in such ridicilous way in Gentoo.
(In reply to comment #2) > Or we could simply move to just good, bad, ugly, base, and gstreamer and add > USE flags to them and this bug would be really easy to solve. Removing myself > from CC because gstreamer is packaged in such ridicilous way in Gentoo. > What advantages has the current way of packaging gst-plugins? (if this is not the proper place for discussion, please tell me the proper one) Thanks
the advantages of split gstreamer is the same to lead to split gnome python bindings. That is: * do not pull kilometric list of deps * do not build useless stuff * do not recompile everything each time you change a useflag (this point is debatable but for me it happens often enough that it annoys me each time I have to rebuild ffmpeg or mplayer). gnome python bindings was easier to do though because: * we had the experience of what went bad in gstreamer split * we didn't bother with making tests run because they were mostly non-existent and not able to run isolated from the system anyway. If it was needed to make them run it wouldn't be that hard I guess since they are isolated from each other iirc. * split package don't change from one meta to another but even if they did, the patches we submitted to upstream would allow us to do this transparently to the user and painlessly since we don't list individual plugin names in the meta * we keep split packages, meta, ... locked to each other versions sure this adds a bit of maintenance overhead, but it's so much nicer for users (and I'm a user of this goodness too so I feel happy). If you feel so bad about the current state of gstreamer, the only thing I can propose is to rework the existing eclasses, eventually providing patches that would make this stuff as easy as with gnome python bindings, so that only one eclass will be left and the rest would only need to be handled by some monkey scripting.
On the other side, the problems brought by the split are: * You can't run the tests on the split plugins * It takes a lot more time to compile, because we have to run configure 30 times instead of 4 * Its a pain to maintain * Users don't get all the plugins with external deps because we're too lazy to make packages for them all * It makes it easier for users to screw up by mixing versions That said, this bug is about installing libcheck.. And its just invalid, we need libcheck to build libgstcheck which is required to run the tests in all of the other gst packages..
This bug is not invalid. The point is to not need dev-libs/check on systems that don't run FEATURES=test on anything (or anything gstreamer). You made it unconditionally pull it in, even if nothing deps on it. The solution could be a dev-libs/gstcheck or some such split out that compiles and installs only the libgstcheck library, then the eclass could add that to DEPEND when USE=test.
I guess we could use USE deps here.. if we move everything to EAPI >=2
I think I already stated a possible clean solution in comment #7: "The solution could be a dev-libs/gstcheck or some such split out that compiles and installs only the libgstcheck library, then the eclass could add that to DEPEND when USE=test." Can't we do just that in the long-run with some configure.ac/Makefile.am improvements to allow that?
I don't think separating this library from the others is possible without massively hacking the build system.. And really, I don't see why you're so upset about tiny libcheck
Thanks Gilles and Olivier for explaining me your points of view
(In reply to comment #9) > I don't think separating this library from the others is possible without > massively hacking the build system.. And really, I don't see why you're so > upset about tiny libcheck > Now that it doesn't even install on amd64, can we please fix this to only be needed with a USE = test? Similar to xcb-util perhaps?
(In reply to comment #11) > Now that it doesn't even install on amd64, can we please fix this to only be > needed with a USE = test? Similar to xcb-util perhaps? http://bugs.gentoo.org/show_bug.cgi?id=273290
Sure it works on amd64.. if not, file a bug.
(In reply to comment #13) > Sure it works on amd64.. if not, file a bug. Perhaps I wasn't clear. libcheck will now not install on amd64 due to the bug reported in comment 12. This just exemplifies why you shouldn't unnecessarily add dependencies to packages no matter how "little". Locally, I changed the 10.23 ebuild dev-libs/check dependency to ">=dev-libs/check-0.9.2? ( test )". Does that break something for you?
gstreamer doesn’t seem to use dev-libs/check anymore… is this bug still relevant or can it be closed?
21 May 2010; Olivier Crête <tester@gentoo.org> gstreamer-0.10.25.ebuild, gstreamer-0.10.28.ebuild: GStreamer now has an internal copy of libcheck, removing dep on external one
