So let's try something new. As we are closing in on tagging systemd v256-rc1, let's see if I manage to post a brief mastodon item about major new features of the upcoming release, every few days until the final release of v256. I figure not everyone reads NEWS files, even if curious. Hence let's start today with the 1st post: the new .v/ directories. You know those .d/ directories that are quite popular in low-level Linux packages these days? While .d/ dirs never have been formalized properly…
…usually what they boil down to is that they are drop-in directories: you put a bunch of files in there, and the tool reading the .d/ dir will combine them in some systematic way and process the combination. systemd does this quite widely but many other projects do that too.
.d/ drop-in dirs are great, because they are very compatible with package managers, and allow lose coupling. Every package gets to extend the combined configuration with their own little snippets, with clear ownership.
.v/ dirs are inspired by .d/ dirs, but their semantics are different. The idea is that rather then combining all drop-ins, we insted pick only one drop-in, the newest one by version.
The version is embedded into the filenames of the drop-ins. i.e. if you have a foobar.raw.v/ as a directory, then this is processed so that from the contained files foobar_4.5.raw, foobar_4.6.raw and foobar_5.3.raw we'd automatically pick the newest one, i.e. foobar_5.3.raw.
Many tools in systemd have now been updated so that you can point them to a .v/ directory instead of a specific regular file, and the tool will automatically find the newest contained file and use that.
For example, systemd-nspawn --image= and --directory= do this now, and so does RootImage=, RootDirectory= in service unit files, among many others.
So what is this all good for?
Basically, you can now place multiple versions of the same resource in some dir of your choice, suffix that dir's name with .v/ and the you get some basic version management in place: delete or add new versions by just removing/adding new files, and the tools will find the newest item dropped in automatically.
@pid_eins How does it deal with incomplete files like in-progress downloads in a .v/ directory? I guess it only looks at filenames that are foo.ext.v/foo_ver.ext so any dotfiles or other temporary files are ignored?
@stefanha precisely. Hidden files and files with a suffix that doesn't match the part before the .v/ in the dir name are ignored. Thus any well behaving download manager that creates a temporary file while downloading under a suffixed or dot prefixed name should be very much compatible with this.