control: found -1 runit/2.1.2-55 Hi,
On Fri, 19 Apr 2024 00:32:51 +0000 Jamie Heilman <ja...@audible.transient.net> wrote: > Package: runit > Version: 2.1.2-59 > > I have a long standing installation of runit which does not use the > runsvchdir(8) symlink flipping mechanics. /etc/service is a normal > directory. This isn't some customization I did, this is simply the > natural state of my sid host after years of following sid. It seems you are right, I did some digging and found the following * until 2.1.2-3 /etc/service was shipped as a directory * 2.1.2-4 no longer ships /etc/service at all [I guess that /etc/service does not disappear if is not empty] * 2.1.2-7 ships /etc/service as a symlink (no migration code to deal with /etc/service as directory) [I thought that dpkg would error if there is already a directory where it has to create a symlink, but evidently it does not ?] * meanwhile the new runit-init 2.1.2-6 package has code in preinst with readlink that breaks when /etc/service is a directory * 2.1.2-55 changes the logic around a test in preinstall and fails if /etc/service exists and is not a symlink So if a system has runit installed since before 2016, and runit-init package was not installed at the time, it will simply fail to upgrade to 2.1.2-59.. I didn't see it coming. > /etc/runit/runsvdir/current does exist, and is a symlink to the > svmanaged directory which is empty. The preinst script that attempts > to migrate away from this layout fails because it sets errexit (-e) > and readlink returns non-zero. > > Checking if "$servlink" != '/etc/runit/runsvdir/current' is never > reached. > > Newer installations won't have this problem, they get set up with the > symlink nest that the runit-init stuff uses, but as it stands, older > installs can't upgrade. skipping releases is not supported, but a clean install for each release is not required, and failing to install/upgrade is not ok, even if affects only a small subset of users; not sure about the severity, maybe it is RC. At least the package has to be installable when /etc/service is a directory; probably having a NEWS where is recommended to change to a symlink would be nice > Obviously migrating /etc/service to a symlink > is delicate, I was able to get away with: I have to think about this, but I see trouble, for example > > T=`mktemp -d /etc/runit.XXXXXXXX` > ln -s /etc/runit/runsvdir/current "$T/service" > rmdir /etc/runit/runsvdir/svmanaged [rmdir fails if svmanaged it's not empty] > mv /etc/service /etc/runit/runsvdir/svmanaged [ in this moment /etc/service does not exists, not sure what happens if runsvdir perform a scan in this moment, but it can be dangerous expecially if runit is init] > mv -T "$T/service" /etc/service > rmdir "$T" also, if I remember correctly there is a setup where /etc/service is a mountmpoint for tmpfs, not sure what happens if I move it. Overall it seems that if do that automatically too many things can go wrong. However the code can be used as an example in the NEWS, so thanks for sharing and test it! Best, Lorenzo > > but I can't say that will work flawlessly for everybody. I use > sysvinit and my inittab entry is: > > SV:123456:respawn:/etc/runit/2 > > I tried the same fix on a old guest I had running systemd and it > worked there too, FWIW. >
