Hi Lorenzo, On Sun, Sep 24, 2023 at 07:59:52PM +0200, Lorenzo wrote: > I'm resending this to the bug as requested to have a public record; also > I'm Cc Ian Jackson as he might already be working on this.
Thank you. Giving a more detailed reply now. > Well yes, my problem is that I know for sure that there are runit-init > users (especially downstream) that are hostile to usrmerge and are still > running on unmerged systems on a "wait and see" basis. > And if I understand correctly your usrmerge plan, there will be a > *mandatory* file move so that everything will shipped under /usr and > what they will "see" is that their system will fail to boot the hard > way after /[s]bin is empty. I think this is fairly accurate. I caution though that even what Ian recently proposed to the CTTE entails moving all the files to /usr and populating the currently aliased locations with symlinks. > This makes me unhappy, and I'm trying to understand if and how it's > possible for runit-init to still manage to reach at least an > emergency shell[1] when boot is performed on an unmerged system. I think I understand your point of view, but there is little I can and want to do to support your cause here. > I think I need to farm symlinks for selected binaries under /sbin and > /bin; can runit-init package detect if a system is still unmerged and > do some limited farming without becoming RC buggy? What you want to do here very much seems like it does not belong into any init system. In my view, runit-init should very much assume that systems are merged. Imposing such triggers on every runit user seems unreasonable to me. Having that functionality in an extra package (as you explain later) is more debatable in my view. If your triggers are only relevant for unmerged systems, then I suggest that you simply close this bug, because you do not want to trigger on /bin or /sbin. I'll have to add a note to dumat to stop reporting the issue for runit-init. > I think I need at least /sbin/init, /bin/sh and stuff inside /lib/init, > /lib/lsb/; also, I'm not sure if runit C code will run without > additional symlinks, I need to do some tests. Very definitely, you also need /lib64/ld-linux-x86-64.so.2 on amd64. > I still have to check if usrmerge will be broken by symlinks > inside /[s]bin directories, and who knows how many other things.. As far as I understand it, we require that such compatibility symlinks do not reside in a data.tar (policy requirement). Packages needing such symlinks should add them via maintainer scripts. usrmerge has code to explicitly handle such compatibility links, see https://sources.debian.org/src/usrmerge/37/convert-usrmerge/#L173 where it ignores them. So this aspect should be a non-problem. Helmut
