There is a feature in Debian that I find missing in Debian, I wonder if
other people would agree with me.
I call that feature "layered package manager".
Here is what it means. The system has "layers" defined, organized as a
directed acyclic graph, and packages are contained in layers. For example:
base
/ | \
/ | \
v v v
nonfree gnome texlive
\ | |
\ | |
v v |
proprep |
\ |
\ |
v v
all
The idea is this: packages in a layer "see" the packages in the same layers
and in lower layers but not the packages in higher layers (in the drawing,
low and high are reversed). By "see", I mean the dependencies: a broken
dependencies in the proprep layer does not prevent me from upgrading
something in the gnome layer, or a broken dependency in the nonfree layer
does not block an upgrade in base.
When working in a layer, everything works exactly as if the higher layers
did not exist.
The lower layers are visible, though, and merged. For example, in the above
example, when installing something in proprep, if it needs a dependency that
is installed in either nonfree, base or gnome, it will just use it. If is is
not installer anywhere, then it gets installed in proprep itself.
Of course, it means that packages in higher layers can easily become broken.
It is not a bug, it is a feature. Better a system with a few inessential
packages partially broken than a system vulnerable because a security
upgrade on a base package could not be performed. Or than removing the
packages altogether.
A higher-level tool would be necessary to help handling things. For example,
if I try to remove a gnome package necessary for proprep, it proposes me to
reinstall it in proprep instead. Or it would propose a command to perform a
full upgrade in each layer in turn, in a single step.
Users need to be able to choose in which layer they work, including changing
on the fly. The admin should be able to choose the layer for all daemons
too.
Of course, a lot of details would need to be ironed. What happens if the
same package comes in different version from several parents? Can we remove
(=hide) in a higher layer a package from a lower one? Etc.
But I think it would make a very useful tool. Here are the benefits I
expect:
Being able to install incompatible packages at the same time. Of course, I
would need to switch layer to use them both, but that is not a big deal.
Isolate servers. Run servers in a layer where the compilers and other
development tools are not visible. It does not actually add any security but
it may help mitigate or slow down an attack.
Install packages on different filesystems depending on their usefulness:
base system on small SSD, desktop environment and other large packages on
larger but slower HDD, huge docs and games on even slower NAS.
Most important: Being able to add third-party repositories with less worry.
Right now, if I consider adding a third-party repository, or installing a
third-party package, I need to trust both its honesty (of course, any
package can contain a backdoor and take root access) and it seriousness.
With layers, I still need to trust its honesty, of course, but if I install
it in a separate layer, I do not have to worry that it may break something
else or block a security upgrade. It isolated.
So, this is what I dream of. Does anybody have remarks? Know projects with
similar goals? Distributions that have that feature? Other means of
achieving a similar result with Debian?
Regards,
--
Nicolas George
Attachment:
signature.asc
Description: Digital signature