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.
There's also a tool "systemd-vpick" now which makes this accessible from the command line, for use in shell scripts and suchlike.
And that's all for today.
The next post like this you'll hopefully find here in the next few days.
@pid_eins Thanks for the amazing work as always!
I've been a fan of systemd ever since I switched to linux 9 years ago. First init system I was introduced to was upstart. I hated it the second I realized that in order to make my own things start on boot, I'd have to program a shell script. I didn't know shell script at the time.
So yeah, massive thank you for systemd.
@pid_eins Writing this summary has been useful at least to me, thank you.
@pid_eins is the ordering consistent with `sort --version-sort` or `ls --sort=version` ? ( https://www.freedesktop.org/software/systemd/man/devel/systemd-vpick.html is clearly right for picking the same one systemd does, but for debugging I want to see all of them and it doesn't look like it has an option for that; it'd be nice if `ls -v` worked.)
@pid_eins (oh, looking at https://www.freedesktop.org/software/systemd/man/devel/systemd.v.html the "tries left" part might not fit that.)
@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.
@pid_eins But what is the use case? What sort of fragments need to be versioned?
@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.
@pid_eins good work and thanks for the efforts!
@pid_eins any particular version syntax / semantics? Or just lexicographic sort?
@pid_eins Okay, I'll bite: What the heck is a NEWS file, and where would one read it?
might be better to have an official systemd blog (nothing fancy GitHub pages and some builder) with these stuff.
maybe also ask fedora/distro people to contribute too. at least fedora magazine has some nice articles about resolved and systemd.
I'd love to have them all in one place.
@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.
@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.
@quitelost The NEWS file lists this all too, of course. Though in a terser fashion, and together with a lot of other, smaller changes too.