rbp2-device-osmc package depends on nano, not editor

Help and Support
1

I’m a Vim guy, for better or worse. As such, I’ve installed Vim on my OSMC device and was about to remove Nano for the sake of only having one editor installed. What happened next:

$ sudo apt-get remove nano
...
The following packages will be REMOVED:
  nano rbp2-device-osmc
...
Do you want to continue? [Y/n]

Looking at the content of the rbp2-device-osmc package:

$ dpkg -L rbp2-device-osmc
/.
/etc
/etc/systemd
/etc/systemd/system
/etc/systemd/system/fake-hwclock.service.d
/etc/systemd/system/fake-hwclock.service.d/local.conf

$ cat /etc/systemd/system/fake-hwclock.service.d/local.conf
[Unit]
Conflicts=shutdown.target

there doesn’t seem to be a need for Nano (specifically) to be installed, especially if Nano isn’t used non-interactively by any underlying tools. Is this correct?

If there’s definitely a need for some editor to be installed alongside this package, what is the likelihood of changing rbp2-device-osmc’s dependency from nano to a virtual package like editor (which would allow any choice of editor to be installed)?

If not, any chance of this dependency being removed altogether?

2

rbp2-device-osmc is a metapackage that is used to pull in many of the dependencies of osmc.

There is a different version of this package for each platform (rbp1, rbp2, vero) as the list of packages differs between them.

These device meta-packages allow us to control (by way of updating the dependencies) what additional packages are installed on each platform - if we add a new dependency that package gets automatically installed on next update.

You can see the list of dependencies for the rbp2 version of this package here:

Unfortunately any packages listed as a dependency of another package must remain installed otherwise that parent package will get un-installed. In the case of the device meta-package that will cause you major problems as it can lead to a lot of other seemingly unrelated packages getting un-installed, and can also break the upgrade process.

There isn’t really a good solution to this drawback of meta-packages - and we’ve given it a lot of thought. Basically, don’t try to remove anything added as a dependency to an osmc package. Have a look at the following article for a description of the meta-package problem which can also occur in other linux distributions:

If you accidentally cause rbp2-device-osmc to get un-installed by removing one of its dependencies you should be able to fix it by doing a forced reinstall of the meta-package, for example:

sudo apt-get install rbp2-device-osmc --reinstall
3

Thanks for the info. To clarify, I haven’t uninstalled the package, I understand the implications of doing so, and I don’t intend to do this.

I’m just seeking information on why nano is an explicit dependency instead of a virtual package like editor, which would allow the installation of any single editor.

If I’m not mistaken, the nano dependency could be replaced with editor | nano to achieve the same default effect but allow replacement of Nano with other editors. What are your thoughts on this?

4

Because this dependency is what causes nano to get installed during the build process, (most of the build process is done automatically via apt dependencies, not by us explicitly installing packages one after another) if we just specify editor it’s not going to know what editor to install. The meta packages are an explicit list of packages that we want installed as part of a base system.

Having nano installed doesn’t prevent you from installing and using any other editor, (and nano is small and light) and we consider nano to be part of the core OS. So not being able to remove it is a bit of a non-issue.

5

So my editor | nano suggestion above is not viable? Would you accept a pull request for it?

6

The Debian Policy Manual says this about the matter:

so I wasn’t too far off with my suggestion. I’ve gone ahead and submitted GitHub Pull Request #173 in the hope that you are willing to merge the already-completed modification. Please note that this does not change the default behaviour in any way—Nano is still installed during the build process. The only change is that someone can replace Nano with another editor at a later time without breaking upgrades, i.e. increased flexibility.

I can appreciate why most would see it as a non-issue. For me though, it’s an issue—but one that can be fixed very easily, with no harm to anyone, though a one-line patch to one OSMC file (which is now provided above). I can go into detail about the specific circumstances that are making this an issue for me if needed, but they’re not very stimulating circumstances.