From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: [PATCH] gnu: rhythmbox: Add gst-plugins-ugly dependency. Date: Mon, 24 Aug 2015 12:14:05 -0400 Message-ID: <87bndwoe9e.fsf@netris.org> References: <87bne0elu3.fsf@igalia.com> <874mjscqs9.fsf@netris.org> <8737z9b08k.fsf@igalia.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34939) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTuOM-0006Bo-44 for guix-devel@gnu.org; Mon, 24 Aug 2015 12:14:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTuOJ-00009p-Eb for guix-devel@gnu.org; Mon, 24 Aug 2015 12:14:38 -0400 Received: from world.peace.net ([50.252.239.5]:55074) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTuOJ-00009R-Bb for guix-devel@gnu.org; Mon, 24 Aug 2015 12:14:35 -0400 In-Reply-To: <8737z9b08k.fsf@igalia.com> (Andy Wingo's message of "Mon, 24 Aug 2015 09:43:07 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Andy Wingo Cc: guix-devel@gnu.org Andy Wingo writes: > On Fri 21 Aug 2015 22:47, Mark H Weaver writes: > >> Andy Wingo writes: >> >>> Not sure what the right solution to this mess is; ideally a user would >>> just have to install a set of gstreamer plugins and those would work >>> across all of their applications, and you wouldn't have to specify the >>> plugins for each gst-using app. Dunno. For now this works better than >>> not being able to play mp3s tho :P >> >> I don't think we should apply this patch. Instead, please set >> GST_PLUGIN_SYSTEM_PATH to ~/.guix-profile/lib/gstreamer-1.0 and then >> all gstreamer plugins installed in your profile should be available >> to programs based on gstreamer. Works for me with totem, anyway. > > Is that the right thing even if you have multiple GStreamer versions > installed, I wonder? Well, if that's a problem, the same problem would exist on a more traditional distribution. I should explain why I don't want to add gst-plugins-ugly as a dependency: it would mean forcing users to always install these patent-encumbered codecs, even if they don't need MP3 support and want to avoid the associated legal uncertainties. More generally, it's contrary to the idea of plugins for every program that uses gstreamer to include as inputs the entire set of plugins that anyone might want. The whole idea of plugins is that users can choose which ones to install. > And why is GST_PLUGIN_PATH not sufficient and you have to use > GST_PLUGIN_SYSTEM_PATH? I guess that either would probably work, but honestly I don't know. > Also, this line doesn't appear in my .guix-profile/etc/profile. Why is > that? For the same reason that I explained in my last email in this thread, although I forgot to mention ~/.guix-profile/etc/profile: Note that we have a 'native-search-paths' specification on the 'gstreamer' package, so if you install that package in your profile, it should remind you to set GST_PLUGIN_SYSTEM_PATH. So, if you install 'gstreamer' in your profile, then I guess that a proper setting should appear in ~/.guix-profile/etc/profile. Quoting myself again: Unfortunately, this is not very satisfactory because there's usually no reason to install gstreamer in your profile. It would be good to find a better solution to this more general problem. Ideally, it would be good to remind the user about 'native-search-paths' for all *run-time* dependencies of the packages in the user's profile. >> What do you think? > > No real opinion, but some questions :) The experience installing > rhythmbox is pretty bad though. I agree. I think we should populate ~/.guix-profile/etc/profile with 'native-search-paths' not only from the transitive propagated-inputs of the user's profile, as we currently do, but from the transitive *run-time* dependencies. That should solve many problems like this. It may be tricky to implement, however, since the run-time dependencies are not known in advance, and I guess it would involve getting the information from the daemon. This is an area where my knowledge is quite weak, so I'm hoping that Ludovic will take an interest in this. Mark