Bugzilla – Bug 4787
OSDetect::dirsFor('Plugins') not correct with 7.0a1 unstable debian package
Last modified: 2008-12-18 11:12:53 UTC
On my debian sid (unstable) server I recently switched from using the SVN tree directly to using the slim provided nightly debian package and lost all plugins in the process. When the web interface refused to come up recently because of references to the Transportor digital input plugin I finally took the time to track the problem down. It seems that the PluginManager::init() calls OSDetect::dirsFor('Plugins') and gets returned a list of two items, /usr/sbin/Slim/Plugin and /usr/share/slimserver/Plugins. Unfortunately all the included plugins are located at /usr/share/perl5/Slim/Plugin, so no plugins are loaded The first path is created off the $Bin directory which for the debian package is /usr/sbin (at least that is where the main slimserver script is located). I have an ugly little hack I will attach that gets around the problem on my system, but I am not sure if fully addresses the root problem.
Created attachment 1820 [details] Ugly little hack This isn't pretty, but it gets Plugins working again on my system.
Plugins are being reworked as per bug 4112. 7.0 is not designed, nor will it be accepting old plugins without the plugins being written to conform to the new API. 7.0 is considered highly experimental, recommended only for those who are actively involved in testing/patching.
Updating the summary to better indicate the problem, which is a mismatch between the debian package and the OSDetect::dirsFor() function and not an issue with Plugins themselves. Perhaps this bug report should be moved to a different Component, but I am not sure which Component would be more appropriate.
ah, that's different. Debian munges the locations for internal files. As ugly as it is, the Slim tree gets installed under /usr/share/perl5, so it would appear the "ugly little hack" is exactly what will have to be done. However, the bigger problem will be fedora, which seems to simply install Slim/* to somewhere on the system that matches the %perl_sitelib.
looks like the best global fix in both the Debian and RHELorFC (possibly even all cases) is something like: + if ($dir eq 'Plugins') { + use Config; + push @dirs, catdir($Config{installsitelib},"Slim/Plugin"); + } As I don't have a debian install, would you be kind enough to try this and let me know if that works out for you? thanks.
On my debian(sid) system: $Config{installsitelib} = /usr/local/share/perl/5.8.8 It looks like either of these would work instead: $Config{installvendorlib} = /usr/share/perl5 $Config{vendorlib} = /usr/share/perl5 The debian/rules files hardcodes the /usr/share/perl5 path, while slimserver.spec uses the %perl_sitelib so there may not be an easy global solution as long as the packaging is done differently on each platform.
This should be fixed for 7.0 at change 11543 I'm leaving open as we may wish to take another look at the debian change specifically. if the path changes, we'll have to edit this in the Debian rules as well as OSDetect::dirsFor. However, both could be adjusted to use the installvendorlib config variable so that this can be automatically matching the varying system configurations that might come up.
I just checked change 11563 and this is working now. Thanks.
KDF, I am going to assign this one to you for now if that is OK. We have implemented a new scheme that all new bugs are now assigned to qa@slimdevices.com until we get a chance to look at them. Once we look at them we either assign them to ourselves or someone else. The goal is to keep bugs assigned to qa@slimdevices as small as possible. Thanks!
Hi Steven, if there's a change number listed, you can just go ahead and mark the bug as 'fixed'.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.