The Ur Project

Documenting the craft of stacking things so they remain stacked. For a very long time.

Architecture - Intent, subpackages, and sets - part 6

There's more ways to get a package

The Ur Project has a standard package layout - most familiar to people who have used Linux for a long time. There's subpackages. Essentially everything is a subpackage. So we've done away with the concept of a main package entirely - let's not waste our time making some packages special.

<packagename>/<subpackagename>

How that looks is rather simple. If you sudo pkg install bash then the pkg utility will install bash/bin. It also will look at bash/bin and install the required dependencies for that, if there are any that aren't installed yet.

But you could just as well do sudo pkg install bash/bin as well.

If you like man pages

By default, when you install any package, you will get the core subpackages that make up the functionality. This is great for most users, but there comes a time when you need that man page. And some people just plainly want the info pages installed at all times.

pkg allows you to declare which subpackages you want to have installed at all times, if they are present in the package you are installing. You have to declare them systemwide in /etc/pkg.toml. Here's how mine looks:

[install]
include_subpkgs = ["man", "doc"]

There's a pkg.toml(5) man page explaining this feature

The above configuration makes pkg install /man and /doc subpackages, but, on top of that, it will also:

If you are a non-English speaker, you'll want to add your own lang/zh_CN to this list if you're Chinese - you'll automatically get all the needed locale for the one provided.

Intent

The package manager keeps track of what you install based on intent. If you installed foo/man it will list that exactly in the listing of pkg list. If you install gcc you'll get more than just gcc/bin but the pkg list will show that you installed gcc with a bunch of other subpackages as well.

This helps to keep a view over what you chose to install, and not how it exploded into an unreadable list - there's no way a normal user can parse 500+ package names and remember when they installed it and for what reason. And the simple explanation for that is that they never did that. Most likely, they installed a set or a few fun tools, and the rest that got dragged in were exploded instead of marked as unintended. All context lost.

Sets

As shown in the previous post, sets are nothing more than lists of packages. They can be main packages, such as gcc. Or they can be subpackages, like kernel-headers/dev. And sets can also contain sets in themselves.

There's good reasons to make it this complex. It avoids having to elaborate individual groups repetitively and allows grouping for occasional functionality splits. E.g. some users want gdm but not GNOME. The +gdm-login set provides just the login manager side. But if you install the +gnome set, it also pulls in the +gdm-login set, since they're strongly tied.

Installing a set also tracks the set for you. If a set changes, the package manager discovers this during an upgrade and will either remove items no longer pinned as part of the set, or install them as part of the set, if they were added. This helps to prevent issues with the sets changing over time and your local install falling behind.

--sofar (aka Auke)