ack...please no.

Sooooo...since this is merely an enhancement request -- NOT a bug report, and a bottom-of-the-stack enhancement request at that, I take it that your response constitutes "no" vote?  Please explain to me again exactly how bitch-slapping bug reporters and enhancement requesters furthers development?  

We're all trying to contribute to the success of this software in our own way.  You write good code, KDF.  No one disputes that.  Some of us don't write good code and are limited to discovering and pointing out deficiencies.  And sometimes, the deficiency that one of us will point out will seem like nothing more than noise to a developer.  But, you can't count on that always being the case.  A response of "ack....please no"...I interpret that as you telling me "oh gawd, will you just please go away."  Do you really want to do that?  What if the next issue I have in my personal "hopper" is a real bug?  Do you really want to inhibit bug reporting altogether, or would you rather reduce the level of noise?  If the latter, may I suggest that, rather than coming back with a response that is in danger of being interpreted as sarcasm and judgment, you might try something along the lines of:

"Hummm...I see what you mean here.  But, since running from svn code is a non-standard deployment, and since no actual impairment of function is involved, is this really a problem?"

Granted, that does take longer to type than "ack....please no".  But it's good for you.

I realize that my bloviating, moralizing sermon here is as likely to tweak you as your "ack....please no" tweaked me.  That's not my intent, so let me sign off by saying:

kiss, kiss, hug, hug.
  

erm..what bitch slap?  I just don't want it.  I don't like the dirs all over the place and do not want to be forced into it without having installed a package.  Simple as that.  No need to get so defensive or confrontational.  I did say please.

note: if you want to emulate a given packaged install, see Slim::Utils::OSDetect.

for redhat, this is isRHorSUSE(). In this case, it looks for osname matching 'Red Hat' and that slimserver is being run using the /usr/libexec/squeezecenter binary.  For svn, this is not the case.  There are any number of ways to run /usr/libexec/squeezecenter and still use the svn modules.  You can link to the usual locations.  I expect that simply linking /usr/libexec/squeezecenter should work.  svn checkout should remain generic.

Sorry about the bitch-slap comment.  And the "dirs all over the place" thing...I guess I've drunk the kool-aid on that one.  Also, I agree with you about the desirability of svn checkout remaining generic.  

But the svn code is already doing some of this kind of thing in other places.  See bug 6827.  Really, since confdir and logdir and cachedir can all be specified at run time, why not userplugindir too?

I won't comment on whether I agree with this request, but a point of clarification...

I think it's an overstatement to call the old Plugins location "deprecated".  The RPM and deb move it to /var/lib for FHS reasons and this is IMO a pretty standard way to build packages.  Note that the "official release" tarball will behave exactly the same as your svn checkout.

Re "deprecated"...point taken.  I guess I REALLY drank your kool-aid.

OK, amending my own enhancement request:  no request for a change in the current default code behavior.  But, instead, requesting a --userplugindir run-time arg to optionally specify where to look for user plugins.

command line seems reasonable.

I've never been clear on how the command line options for the various paths interact with the platform specific dirsFor stuff in OSDetect.pm.  Which one has precedence?