Hi there,
I had a spare raspberry and decided to put Raspbian on it, main goal BTSync and perhaps later Owncloud.
Raspbian was a disappointment since it lacks support for NTFS, no HDParm or HD-Idle, and even the Raspbian config didn't work well: I changed the hostname using the config but only the /etc/hostname file was updated, not /etc/hosts causing problems connecting (and an error everytime I used sudo).
XBian seems to be better suited for me, less manual installations are needed, better out-of-the-box experience. Perhaps even more optimised/tweaked.
I would like to know if it is possible to uninstall XBMC (and related/required packages) in XBian, and also prevent them from being installed again when updating?
I still use Raspberries as XBian mediacenter for myself and others, I am just planning to switch to Cubox+XBian in the future and now want to start using the first spare Raspberry for other goals.
Please open an issue about it. I already discussed this earlier with @mk01.
Unfortunately after removing the xbmc package only, apt-get will stop working. If I want to install anything, it won't work because of the dependencies, it misses XBMC. How do I cut those dependencies?
Any tips for me?
I would also like to disable HDMI output. From what I know, that could save power consumption. How can I do that?
(8th Nov, 2014 02:35 AM)zilexa Wrote: [ -> ]I would also like to disable HDMI output. From what I know, that could save power consumption. How can I do that?
you can try to add this line into your config
Code:
hdmi_ignore_hotplug=1
To enable or disable HDMI output at runtime:
vcgencmd display_power 0|1
I'm not sure if the firmware shipped by XBian is recent enough though. To verify execute "vcgencmd display_power" without parameters, it'll show the current status.
xbian@xbian ~ $ vcgencmd display_power 0
display_power=0
I thought there was still power even if HDMI was not connected, apparently that is not the case, which is good
@
zilexa
edit /var/lig/dpkg/status and remove xbian-package-xbmc from depends of other packages. anyhow it will get back with such pkg update.
another option would be to remove xbmc (dpkg --force-all -p xbian-package-xbmc) and then put into /var/lib/dpkg/status section like xbian-package-xbmc would be installed. so save this section before xbmc remove.
this will survive also other pkg updates.
if we would consider that as USER option, probably in todays situation fastest way would be to create "empty" xbian-package-xbmc, xbian-package-xbmc-scripts and upstart-xbmc-bridge packages. empty means just DEBIAN/* content, no actual files. this is called meta-package and even Debian is using it for various purposes.
more than that, those packages could have -meta suffix (or any other) and in "Provides: " specified the original names. then they can be pushed to APT and provide "alternative" like currently -nightly or -6q or -alsa for instance (so by installing them you would get the actual components removed, but apt-get would stay intact).
you will see better what I mean if you grab such package and extracts it and check the content DEBIAN/control
Code:
cd /tmp
apt-get download xbian-package-xbmc-alsa
dpkg -x xbian-package-xbmc-alsa*.deb ./
then you can create them and push to XBian
it is like 20m work with some experience, 1h without including some try-and-see elaboration.
The problem is that this doesn't actually remove any XBMC related files.
@
CurlyMo
sure it does as XXX-meta is conflicting with XXX (but providing it). that means ATP deconfigures XXX, installs XXX-meta, removes XXX.
take for instance this (-nightly over regular)
Code:
apt-get install xbian-package-xbmc-nightly
dpkg: xbian-package-xbmc: dependency problems, but removing anyway as you requested:
xbian-update depends on xbian-package-xbmc | xbian-package-xbmc-6q; however:
Package xbian-package-xbmc is to be removed.
Package xbian-package-xbmc-alsa which provides xbian-package-xbmc is not installed.
Package xbian-package-xbmc-6q is not installed.
(Reading database ... 26494 files and directories currently installed.)
Removing xbian-package-xbmc ...
Selecting previously unselected package xbian-package-xbmc-nightly.
(Reading database ... 21778 files and directories currently installed.)
Unpacking xbian-package-xbmc-nightly (from .../xbian-package-xbmc-nightly_14.0~RC3-1418634627_armhf.deb) ...
Setting up xbian-package-xbmc-nightly (14.0~RC3-1418634627) ...
Processing triggers for xbian-package-xbmc-nightly ...
Yes, when you let the conflicht it will..., but when they conflict they also conflict with all the other packages that depend on XBMC (like xbian-update) and so you're still not any further.
@
CurlyMo
no, you are not right with that.
This is standard way of handling customised (each enduser installation is a bit different) installs. That allows us to install upstart even when Debian default is systemd. This allows installing of firmware-imx to imx6 images but still provide dependency for xbian-update which is xbian-package-firmware.
This allows installing 3.10.51 or 3.14.14 kernel but not both together (because both provide linux-image target but they conflict to each other).
And the best example is for sure xbian-package-xbmc which can be reinstalled with -nightly while xbian-package-xbmc will be auto removed but xbian-package-xbmc dependency is still met.
Debian is providing that way popular replacements to classic (old) linux services - postfix provides sendmail and removes it because set to conflict. libjpeg-turbo removes libjpeg but still provides it.
And that's why zilexa can provide 3-4 metapackages to remove xbmc and related services but still have fully working xbian system upgrading itself via xbian repositories as before.
I'm curiously awaiting the results of zilexa