1️⃣ 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…
@pid_eins Will all the content of these postings end up in the NEWS file as well? For me that's def a better place to read them, instead of bubbling around "social media". Yes I understand the value of discussion.
@gdamjan I am just too lazy for that. I mean I do have a blog, but I have to say being able to just write down my thoughts into this mastodon form here is so much easier, and people can actually sensibly reply to it without me having to moderate much, and having to deal with spam myself which is great too.
Also, are you sure that putting it on a blog these days would even reach a larger audience than mastodon? Blogs are semi-dead I fear.
@gdamjan that said, if somebody wants to turn this into an article for something like fedora magazine or so (as you proposed), then they are welcome to, I am just too lazy to do anything about that. If somebody else wants though, I would be happy if they did.
…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.
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.
@jeffpc systemd uses disk images for a lot of things, i.e. for nspawn container disk images, portable service disk images, systemd sysext disk images, confext disk images and such.
In systemd, these disk images we call DDI and come with dm-verity and signatures and so on, and it is just tremendously useful to be able to keep multiple version around, becase these disk images are typically periodically updated with tight cycles.
Add comment