What about "packages"?

To say that "packages" have a central role in most general-purpose Linux-based systems would be understating it.

But the reality is that GNOME design is pushing hard for where the rest of the client software industry is - having a clearly defined operating system, and clearly defined applications. Trying to create this model on top of packages leads to fundamental architectural conflict.

Applications vs packages

The PackageKit project has made a truly valiant effort to put a pretty face on the mess, but for example, still hasn't managed to make the process of upgrading (or downgrading) one individual application a well-defined operation. It's possible for example that the package containing an application could have a Conflicts: on another package. Meaning that installing it will uninstall something else (an application? A system daemon? Who knows?)

This leads one down the path of "OK, let's restrict what 'application packages' can do". And once you've started to define "application package", you realize that the characteristics it should have are in fact quite distinct from the package containing the kernel, so much so that it doesn't make sense to call them the same thing.

Upgrade

Most package systems define "upgrade" as "attempt to find new versions of all installed packages". There are a number of interesting side effects to this; one for example is that you don't get new packages unless they're a dependency of something you already had installed. In Debian, metapackages are an attempt to address this; you'd have a gnome-desktop package which depends on everything. But this has the converse problem - there is no mechanism to remove a package which is no longer used, and these stale packages can be very problematic.

The other, less easy to solve issue with this semantic for upgrades is that there are packages which are probably best characterized as "system extensions". For example, the nVidia proprietary driver. What we want to support is a default rebase semantic where the 3rd party proprietary driver is dropped - because we want to encourage people to use nouveau, for example.

Use cases not currently attempted by packages

A concrete use case not served by packages is where a user is handed a locked down device (think centrally managed IT), but should still be able to load applications that can only affect their account, not potentially compromise the security of the entire system (as can be done by loading e.g. RPMs).

Package compatibility and system extensions

Now that I've brought up the concept of a "system extension", would it make sense to support installing RPMs or .debs (to some degree)? The answer to that is probably yes; it might make sense to support installing the nVidia driver RPM.

OSTree underneath a package system

Even if you buy into the idea of "packages" in general, I think OSTree always makes sense to use as a core operating system builder and updater. By "core" here I mean the parts that aren't removable. Debian has Essential: yes, any other distribution has this too implicitly in the set of dependencies for their updater tool.

It would be possible though to introduce the idea of dynamically assembling filesystems on the client (as package systems do), instead of on the build server (as OSTree strongly encourages). For example, instead of having standalone .deb or .rpm files, one could store the data in an OSTree repository, gaining the advantage of transparent versioning and deployment, but having a system that parsed dependencies and such and downloaded, and "composed" roots on the client.

Projects/OSTree/Packages (last edited 2013-11-22 20:27:22 by walters)