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