Note: This is a draft document. Debian seems to have made some improvements and this document needs updating to reflect that. For example the evdev driver isn't required for xorg now, instead the xorg-driver-input virtual package is required which is provided by your input driver of choice. Credit is due when the document is no longer a draft and things have been checked out and crossed off.
ToDo: Explain the issues better. Limit scope of document, work-arounds for these issues are a separate documentation issue.
This document describes problems with additional packages in Devuan that ought to be optional. By this I mean one of two things, either upstream unreasonably requires the software to be larger or Debian does and we inherit these problems as a result. Some of these problems are long standing and have persisted for many releases.
It's worth mentioning that many of these problems can be solved by making these components optional, and this is done for many packages in Debian that are larger by design. But this is not the case for many packages, especially those that can use dbus or pulse even if they are not required.
The reason for this document then, is to point out these problems so they can slowly be solved. This is intended to be an almost complete reference to those problems in the hope that it's useful to Devuan or any other interested parties.
Why? Just why?
There are a lot of reasons why Devuan and it's parent Debian should be simpler even within the model of being universal. Let's take a look at them. Much of this may be a good argument for simpler distros in general, but this is outside the scope of discussion.
Being universal implies that the system will be simple to a degree. Smaller, and more resource limited areas exist and are not outside of that scope. The more architectures and devices that are supported and work well the more universal the distribution will be. Simplicitly and moularity make this a lot easier, since resource usage increases as features do. This is especially true when it's harder to choose between system components to make the distro suit a specific use case.
This is pretty obvious. More features on old hardware will use more resources and slow it down. The more complicated software is under the hood, the slower it will run and take longer to perform basic tasks. Needless to say this is a limitation of old hardware, but it still needs to be supported.
Why is this different than old hardware? My answer is that it's really not. New hardware will also show poor performance when features are enabled by default, which is not to say it will crawl in the current situation. The usual reason to buy new or high end hardware is because they perform so well, but it's not necessarily the case that software performs well.
This is not old hardware at all, and in many cases it's new hardware.
The problem with interpreted languages
There are plenty of good uses for python, perl, ruby and the like. But it can and should be considered a potential security issue to have interpretors when they should otherwise not be needed. When an interpretor is required for the program to run it's expected to be there, and should be there. In that case the user always chooses, but it's a problem when features that are optional (or should be) cannot easily be opted out of.
A good example of this is debconf depending on both perl-base and bash. In the case of the perl hard dependency this has been documented by the securing debian manual for years, which is a good argument for not having a hard dependency on perl aside from the simplicity problems. The case of which shell to use is a lot simpler argument, it should just be agnostic to the users choice of shell. Assuming it could be done the best way in my opinion would be to use dash as the default for debconf, and allow it to be swapped for any other shell that would work.
Especially bloated because pulse support is assumed.
keyboard configuration depends on liblocale-gettext-perl
xfe requires xfe-themes
xserver-xorg-core requires libwayland-server0 and libwayland-client0
xserver-xorg-core depends on libx11-xcb1 even if it's not being used
libgl1-mesa-dri requires installing support packages for libdrm-intel1 and libdrm-radeon1 even if the user does not have one of these cards. libdrm-nouveau2 will not work without libgl1-mesa-dri.
the login package is required eventhough there are alternatives, e.g fgetty.
No separation between client and server package. It all just comes in dropbear-bin.
The openssh-client-blacklist package is now included in the openssh-client package. Whilst this provides some protection out of the box, it removes it as a choice for the user to make.
The openssh-server package has a hard dependency on the openssh-sftp-server package. It's very unclear that a user definitely wants this feature.
An odd one to add to this list.. x11-xserver-utils requires the CPP package. I'm not sure why x11 utilities need a C preprocessor.
I have a rough plan to outline some measures users can take to solve some of these issues. Some of them are a little "hackish" so I don't think I would recommend them.
Bloat problems in ascii
As some time has gone by, I have taken a deeper look at dependencies, alternatives and bloated package selections.
I have covered most of this for Jessie, so here we will take a deep look at bloat problems that concern ascii.
When I talk about bloat, I mean packages that ought to be optional or down to user choice.
This is a draft, so is off the top of my head. Everything needs to be looked at closely before considering it a useful reference.
When talking about the base system a distinction should be made. There is the minimum required packages and those that are installed by default if you make no attempt to avoid them.
Required packages are those that are included no matter how you install Devuan, and based on debootstraps --variant=minbase parameter.
In many cases packages are marked as "required" meaning if you remove them you will have non-stop harrasment from apt telling you that you need these packages, and they will be installed again whenever you install or ugprade a package.
But to be clear on this marking them as dependencies instead of required will only increase the problem, and not allow the user to attempt working around these problems.
In many of these cases a symlink to the busybox equivalent command could potentially replace some of these parts.
The good news is that some things have changed here, and this document is smaller than it would be as a result. As is a minimal base Devuan install.
This is a dependency to many packages, but it's in no way a standard. Some may want this support, but most end users will not want this at all. In addition to this there are many security models available, any of which might be chosen by a user or sysadmin. Tomoyo, AppGuard, Grsecurity with gradm.. all of these provide alternative models to selinux but this one specifically is forced at the library level.
Provides support for extended file system attributes. This is only useful when you intend to make use of those features, but is a hard dependency here.
There are many shells to choose from - the minimal mksh, csh, zsh, whatever takes your fancy and it can be set as the default login shell. The problem here is that bash is a dependent of debconf.
This is a requirement for dpkg. When it's debootstrapping the system calls will be made to gzip so it's not removable for the installation at least.
This is the same situation as gzip.
Perhaps less commonly used than grep or sed, I would class this is an important package more than a required one. I believe it may be required when debootstrapping however.
Handy, and may be required during debootstrap.
This is a long standing issue with Debian. The idea that the base system requires this high level interpreter has never made any sense to me.
The problem is debconf specifically requires perl-base so it's difficult to remove it.
This really isn't required for running a Devuan system. It does provide some terminal utilties but they aren't essential.
My current information about this is that it provides the clear command, and some manual pages for console utilities.
This is not a good thing since the user would otherwise be able to choose to omit manpages altogether.
Nothing in required seems to depend on this package.
Package specific bloats
Bloat problems still affecting ascii.
These have many programs depending on them where they should be totally optional. Meaning it should be treated as a recommended package because some users will definitely want it, whilst some will specifically not want it.
firefox and firefox-esr
These is bloated upstream and I've felt for a while alternative builds should be available with changes like:
EME support disabled in the build.
Pocket disabled in the build
Ads in tabs turned off by default or preferable turned off.
Data health collection disabled in the build
Curretly sysvinit is required by default, but is not priority: required meaning it can be removed. This is the expected default behaviour for Devuan users.
If you really want to you can exclude sysvinit however as it's not priority: required. I need to look into this configuration.
Lately I'm wondering if sysvinit scripts could be simplified, though I would guess that this would only be a small gain.
It's quite possible to use runit in Devuan. It requires copying the basic scripts into /etc/runit from the documentation that comes with it. Networking and others is down to the user to figure out though. It's not easy to solve this since every Debian package would need to come with a runit script as well as the sysvinit script.
This configuration may be difficult from a debootstrap install, but it looks possible.
Currently depends on sysvinit, but the good news is that sysvinit scripts are compatible.
Whilst it's possible to have a different getty installed like fgetty, ngetty etc you will still have /sbin/getty available.
Probably a case of taste, but you may get a more minimal setup avoiding python.
Very configurable and has many features. Most of which are a good thing.
Seems to run slow on ARM SBCs, there may be some way to help this using apt.conf.d configurations. It's worth noting that storage options on these devices are not all as quick as traditional drives, so that's at least some of the issue there.
Pinning is not recommended by Debian (don't create a franken debian) yet is included in apt's default feature set.