Wow, this FHS conversation brings back memories... Robin Bowes;239170 Wrote: > Fletch wrote: > > I still agree with you. I gave in > > to /usr/sbin because: > > - other packages like httpd and smbd that don't run as root are in > > /usr/sbin > > Ah, but they bind to privileges ports so need to start as root. > slimserver does not. > > > - Dan wanted to be consistent with the Debian package > > That's just wrong - this is not a debian package. It is an RPM for use > on Redhat-flavoured systems. It should follow Redhat packaging > guidelines.
But there should be one FHS answer that is correct for both. I think we should try to do the right thing and our changes can be "backported" to Debian later. Certainly, it will be easier to support if the RPM and DEB use the same file locations. > I would put it in /usr/libexec I'm starting to lean toward /usr/bin. After all, there are reasons why a user might manually run these programs, especially the scanner. > (actually, I would put the whole lot in /opt, and /var/opt but I've > lost that battle!! :) ) :-) Even though that's not how any of the Fedora add-on repos do it? > Hmmm. Well, the O/S CPAN dir goes in /usr/lib/perl5/5.8.8/CPAN. The Slim > stuff could go in /usr/lib/perl5/site_perl/5.8.8/CPAN or even > /usr/lib/perl5/site_perl/5.8.8/Slim/CPAN It just seems to me that the perl site_lib area is for perl modules to be made available for the system. I can see where other 3rd party apps might want to use the Slim:: stuff. Everything in CPAN and lib are versions of modules that are only for our use (and might have system versions installed under perl). I don't know... > What does "Autoreqprov" do? When on (the default) it enables some rpmbuild magic that parses all the perl files and automatically creates the necessary "Requires" and "Provides". The contents of CPAN and lib really mess this up. > If arch-specific code is included in the RPM then it should be an > arch-specific RPM. So I guess this means separate i386 and x86_64 RPMs. > In fact, it's arguable that the rpmbuild process should run > build-perl-modules to create the arch-specific files on the platform on > which the RPM is being built. But it really isn't an arch-specific RPM. It can run on various arch's, there's just some added files to make i386 and x86_64 easier. I think building multiple arch-specific RPMs is unnecessary and adds a level of complexity that SD probably won't like. I've thought about running build-perl-modules during %post. That way it could still be a noarch RPM. > True, but the MySQL RPM puts the default DB under /var/lib. I'm just > following precedence. In my mind, the difference is that in our case the mysql tables really are variable cache data that can easily be recreated if deleted. > The ideal solution would be to sort out the mess and put the stuff that > is "valueable" in /var/lib/squeezecenter and everything else in > /var/cache/squeezecenter. I'm not sure how feasible that is. Agreed. I'm sure it's feasible, but will require more than just packaging changes. > Oh, and the pref file should definitely go in /var/lib/squeezecenter, > *not* in /etc/squeezecenter. :-) I hate the fact that the prefs file(s) are a mix of "static config data" and "variable state data". I don't think this will change anytime soon. Overall, I don't disagree with most of your points. I think there's a lot more gray area here that I'd like. For the time being, I'd like to leave things as-is and continue to request feedback and discuss. -- Fletch ------------------------------------------------------------------------ Fletch's Profile: http://forums.slimdevices.com/member.php?userid=529 View this thread: http://forums.slimdevices.com/showthread.php?t=39789 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
