Hi,
I started to look into creating a Debian package (which could be apt-get) and I want to hear some ideas how it should be implemented. The possibilities are:
1. Install all XBMC under /usr/xbmc with read/write permissions to a group called "xbmc". Only users in that group will have the option to run/write/read from that directory.
2. Break the XBMC tree into several locations: binaries and scripts go to /usr/xbmc, user data goes to $HOME/.xbmc/UserData, etc, etc. This is a bit more problematic as it requires possible code changes and it also requires to be root in order to install scripts for example.
I'm open to other ideas and comments.
Thanks,
-Yuval
Hi yuvalt,
very nice idea! but please take a look at
http://www.us.debian.org/doc/packaging-m...s-2.3.html.
my suggestions:
* /usr/share/xbmc (main program)
* /etc/xbmc/ (softlinked main configs like advancedsettings.xml, sources.xml etc.)
* $HOME/.xbmc/profile (user profile if using profiles)
The best way would be a system user "xbmc" with no shell (/bin/false) who runs the entire media center, so theres no need to be root to install scripts or skins into the xbmc folders. Only some scripts need interactive editing, but this could also be done by "better" scripting, so scripts get configured on screen without an editor.
Maybe we could also package skins and scripts to be installed via apt?
Regards
asciii
My opinion is I prefer the first method -> /usr/xbmc
xbmc itself controls the xbmc-users` permissions. So a PC with Xbmc-Linux should boot into xbmc and _then_ users can login like in the "normal" XBMC on Xbox.
is option 2 compatible with all distros ?
Option #2 is much more work than option #1 but it is cleaner in terms on FHS. In option #1 we just dump everything under /opt/xbmc and require a special xbmc user to run everything.
Option #2. Really. Leave everything in the /usr/xbmc/ as the defaults, and when a new user runs the program, it should copy default configs to ~/.xbmc where all config changes are made on a per user basis. So when loading configs(and skins and scripts), it should start by looking in /usr/xbmc, and then it should add anything found in /etc/xbmc, and then last it should add anything in ~/.xbmc.
Another way to put it would be:
1. The Defaults
2. System specific settings (video and audio choices)
3. All the User stuff (skins, .
There should also be settings that can be locked out for the users for the overbearing fascist admins out there.
Don't you think it's a little bit too much for a client application? Is it really going to be used on a multi-user environment?
I think I'll start with building a distro with option #1 under /opt/xbmc and start getting some feedback from the community. If there's enough screaming, I'll fix it...although it's a very big fix in the way XBMC is written.
Given that this is most likely for single purpose computers, you're probably right. At minimum there should be separate directories for files included in the distro, and files that are modified by the user though. Maybe you could change /UserData to ~/.xbmc/UserData and add secondary search directories for scripts as and skins as ~/.xbmc/scripts and ~/.xbmc/skins.
Also, system type things like which default audio out to use and what default video mode to use should be kept in /etc/xbmc.
I really hate to see users having to make modifications to /usr/xbmc.
That's why I said it should be /opt/xbmc and not /usr/xbmc
yuvalt Wrote:That's why I said it should be /opt/xbmc and not /usr/xbmc
Either works. /opt is the better choice from an ideological standpoint, but from a programming standpoint, there should be little difference. The program should execute from wherever in the directory tree it is and look for initial configuration in relevant positions from there. Any way around it should be looking for configuration in the program directory, the etc directory, and then finally in the user directory.
/opt/xbmc is a much better location than /usr/xbmc if you're not going to put everything in the correct FHS locations. i find config files in /opt acceptable.
ideally we should make decisions that will apply across all distributions. that probably won't help you get the deb created any quicker though.