Now that I think of it, I really regret I didn’t make systemd ebuild install it to \/usr from the very beginning. But the harm has been done already, and I’d like to move it ASAP and that’s why I’d like to sum up problems with that and possible ways of proceeding with it.<\/p>\n
The idea is simple as it is: move systemd install to \/usr prefix completely. Right now, there are no technical benefits from keeping it in rootfs. It already depends on libdbus, which is installed in \/usr, and I expect more dependencies over time. There’s no reason to move all those packages into rootfs.<\/p>\n
Most importantly, the above information allows me to assume that such move won’t hurt our split-\/usr users \u2014 because they already had to have \/usr mounted for systemd to run.<\/p>\n
<\/p>\n
The main problem with the move is that unit files were installed into \/lib location by a number of packages. The files can be moved into the new location cleanly only through rebuilding the packages which provide it. They need to stay in search path for systemd to work.<\/p>\n
These unit files are symlinked from within \/etc\/systemd as well. Whenever we move a single unit, we need to update the symlink as well. I’d really like to avoid forcing users to manually fix that, and the eclass doesn’t export The last problem is that people have the systemd location hardcoded into the kernel command-line. This one should be relatively easy to avoid as we can keep compatibility symlink for some time.<\/p>\n The simplest solution for the migration is to move all the relevant units in the systemd ebuild. This way, the unit integrity can be preserved, and symlinks could be updated at once as well. The risk of system breakage should be reduced to minimum.<\/p>\n However, there is an important disadvantage of that method. All those files would be moved out-of-scope of the Package Manager. Thus, after rebuild of every single package providing systemd units, all of our users will have to fight file collisions.<\/p>\n The same will likely apply to our new users, because they will have at least some units installed by random packages already. Users not ever intending to use systemd won’t be hurt because the move of unit files will be transparent to them as any other package file move.<\/p>\n Right now, systemd already supports multiple locations for unit files. As a temporary hack, we could just add \/lib\/systemd\/system to that list. This way, all unit files still installed in \/lib will still work as expected when systemd is installed into \/usr.<\/p>\n Sadly, this won’t handle updating \/etc symlinks. I could, however, fix that easily by adding a simple Well, I think the second one is the best we can do. Do you have any other ideas? I guess that udev could face a similar problem if we decide to actually move it into \/usr. And there the thing is even worse because the rule install location is usually hardcoded into the ebuild or package build system itself; we will probably need to have even more degree of compatibility.<\/p>\n","protected":false},"excerpt":{"rendered":" Now that I think of it, I really regret I didn’t make systemd ebuild install it to \/usr from the very beginning. But the harm has been done already, and I’d like to move it ASAP and that’s why I’d like to sum up problems with that and possible ways of proceeding with it. The … Continue reading “Moving systemd into \/usr \u2014 the technical side”<\/span><\/a><\/p>\n","protected":false},"author":137,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[6],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/113"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/users\/137"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/comments?post=113"}],"version-history":[{"count":3,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/113\/revisions"}],"predecessor-version":[{"id":213,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/113\/revisions\/213"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=113"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=113"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=113"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}pkg_postinst()<\/code> which could help doing it automatically.<\/p>\nSolution 1: one big move<\/h2>\n
Solution 2: temporary support for two locations<\/h2>\n
.path<\/code> unit or another solution updating symlinks as soon as files are removed from \/lib.<\/p>\nOther solutions?<\/h2>\n