Sometime between mythtv-0.27.5_p20150627 (now removed from portage) and mythtv-0.27.5_p20151025.ebuild, including mythtv-0.27.6_p20160318 a dependency was added for sys-fs/udisks if either the dvd or bluray USE flag is set. While I don't use bluray support, I do use dvd, and this wanted to install a massive list of bloat all caused by sys-fs/udisks including things like polkit etc.
Since I knew that mythtv-0.27.5_p20150627 always worked for me without that, I copied themythtv-0.27.6_p20160318 ebuild into my local overlay and removed that dependency. Everything built fine, and dvd playback is fine from either the physical DVD drive or VIDEO_TS etc.
If there is in fact some reason for that change, it would be great if it could possibly be a separate USE flag or the like, because that ends up being a very heavy dependency for someone not already using all that.
See bug #456898 and bug #503806 explaining why its a dependency. I can't fathom another USE flag that we could possibly use to break this out in a clear fashion. Any other MythTV maintainer have an idea?
This is a bit of a soft runtime dependency. MythTV tends to go looking for udisks and if it doesn't find it at launch time it just goes on without it, after some delay. I imagine that DVD playback might not work without it, but otherwise it isn't easily noticed.
Really the two options I see here are either make it a dependency on the USE flag as it currently is, or not make it a dependency at all and just output a message suggesting to install it.
My feeling is that we have it correct right now. If somebody really doesn't want udisks around but wants to build with DVD support they could always put it in the provided packages list, or fork the ebuild, etc. The current ebuild provides the "just works" experience which is probably the best one for the main repository.
I'm curious as to when DVD playback wouldn't work without udisks. That's never been an issue for me. I though udisks was related more to mounting drives etc, where DVD playback reads the raw device. DVD playback has always worked perfectly for me (using any media player program) by virtue of the user belonging to (in my case) the cdrom group (the group assigned to the raw device). I'm certainly not aware of any requirements beyond that.
The udisks dependency pulls in a seriously massive amount of stuff. It's bad enough that I have to install dbus because of the gtk+ -> glib -> dbus hard dependency (especially given that I've never even started the dbus service)...but I digress ;).
I read those bugs and I'm still totally confused by this. It sounds as though it may be related to something regarding dbus(?), but I'm not understanding it at all. What I especially don't get is what anything regarding "mounting" has to do with DVD playback. I've never even mounted a DVD except for ISO format data disks.
I just verified that none of either vlc, mplayer, or xine ever pull in udisks for any reason. Is dbus doing something odd here that causes this requirement?
Again, it's an awfully heavy dependency pulling in the likes policykit etc. If I have to use an overlay to fix this I will, but I really don't understand this requirement that no other media player seems to have, especially when I've been playing DVDs in MythTV for seven years (and more like 16 years with other players) without it.
Reading more closely, I think I understand this one. Correct me if I'm wrong but it appears the only purpose of udisks here is for to allow the UDisks DBus service to detect DVD and Blu Ray devices(?). In my case it's probably just using the DVDDeviceLocation entry in the database, which is correct and works.
If that's the case, that's seems like a pretty big hard dependency for something like that, especially for Gentoo. Is there any possibility of a use flag that's on by default, so as to not break things for anyone who needs that?
Let's see what happens with your mythtv-users thread. If we can make dbus optional I'm sure we're all for it. We should just understand what the implications are, etc. Depending on what we find we might or might not default it on vs just accepting whatever is in the profile/etc.
That sounds perfect. I see there's one reply already indicating that MythTV works with QT less the dbus support.
In addition, I may just go ahead and remove the QtDBus from my frontend and hack an ebuild so as to omit that dependency and see how it goes for myself.
If all that pans out and dbus itself can be made optional, it may make sense to require udisks for dvd and bluray support based on the dbus USE flag...assuming I'm correct in that it's only purpose is for the UDisks DBus service drive detection.
Thanks for your attention to this! I'll let you know how I make out.
Please do test if you're able, and I can try to do the same. I'm in a bit of a family emergency right now so I'm still dragging my feet on 0.28 (that is basically ready to get unmasked as soon as I disable the logserver by default - it turns out openrc should work fine without it).
I just tested this on my frontend and everything seems fine. Since the mythtv build bases the dbus stuff on "pkg-config --exists QtDBus" here's what I did:
I removed the dev-qt/qtdbus dependency from my ebuild, uninstalled dev-qt/qtdbus, and recompiled mythtv. Just to make sure, before and after I did:
ldd /usr/bin/mythfrontend |grep -i dbus
libQtDBus.so.4 => /usr/lib/qt4/libQtDBus.so.4 (0xb481b000)
libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0xb1a8f000)
...and after the re-compile those were gone and all works great. Next I have to change a few things to allow me to totally get rid of dbus, but mythtv clearly isn't using it, so all looks good.
Cool. Both my backend and frontend are running perfectly with dbus completely removed. Looking good.
It seems like the only real decision here is around how best to handle the USE flags in the ebuild. I'd say that the lack of the dbus USE flag should certainly cause both QtDBus and udisks to be excluded in all cases. It's a safe bet that those who have dbus off have no plans on using any of that.
I'd say the open question is whether or not the udisks USE flag is or isn't observed for dvd and bluray support in cases where dbus is in fact in use. That's a little tougher call I suppose, given some of the "it just works" functionality that udisks adds.
master 4ccabfe2d08] media-tv/mythtv: Per mythtv/libs/libmyth/mediamonitor-unix.cpp this is also compatible with udisks:2 finally (#580856).
1 file changed, 362 insertions(+)
create mode 100644 media-tv/mythtv/mythtv-0.28.1-r1.ebuild
I'm a little confused as to this getting marked as resolved. The original bug had nothing to do with udisks 1 vs udisks 2 at all.
It was about the fact that the hard dependency on udisks and all it's massive dependencies including QtDBus and dbus are not actually needed at all for DVD or Blu Ray playback. They're only used for optical drive detection.
I understand that we apparently have no maintainer here, and something like the addition of USE flags for this surely won't happen soon, but in the mean time I'd think this could be left open? Thanks.
We cannot make the ebuild with more conditionals (it's already conditional behind , if we drop the dep completely it will simply be hidden but still used in an "automagical" way https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Automagic_dependencies
The dep is clearly used, I see it behind CONFIG_QTDBUS... but as I see in the sources, that is set to "no" only for building in windows, for all the others it is mandatory. If you want to get that qtdbus support disabled, please report to upstream.
Wow...now I'm more confused than ever. I've been running MythTV for years with no dbus support in Qt, as has been discussed at great length, both here ans with MythTV devs on the mailing list:
I can understand if the USE flag isn't an option at this point, but just to be clear, it absolutely isn't mandatory at all.
They replied you some of its usages:
But, anyway, they need to fix their build system to really make QTDBUS detection optional (or, finally, drop it completely). Also, looking that finally it was adapted to also use udisks2... I wonder if they really pretend to drop all that usages.