On Mon, 27 Nov 2023 02:24:43 +0100, Lorenz wrote in message
<CAOEhTLyGuNHPKc3vXSdEvzEJpodvLLHjwycamEuL-GNkEAF1xw@???>:

> Hi Martin, hi List,
>
> Il giorno dom 26 nov 2023 alle ore 11:49 Martin Steigerwald <
> martin@???> ha scritto:
>
> > Hi!
> >
> > I just upgrade to runit 2.1.2-54+usrmerge on Devuan Ceres and it
> > gave me the following output:
> >

> >    === WARNING ===
> > unmerged system detected via /sbin
> > warning: unmerged systems will fail to boot very soon
> > due to /[s]bin/ directories becoming empty!!   <----THIS IS THE
> > PROBLEM !!!
> > please merge this system as soon as possible
> > for details refer to DEP17 (M2) documentation
> > https://subdivi.de/~helmut/dep17.html

> >
> >
>
> > Do I need to merge usr on my Devuan Ceres systems in order to
> > prevent boot them failing *very soon*. Or is that hint only aimed
> > at Debian users?
>
> Yes you need to perform the merge on Ceres.
> If you are using Stable (Daedalus) you can still run unmerged but you
> need to
> remember to perform the merge *before* you ugrade to the next stable
> (Excalibur).
> If you are tracking testing or unstable you need to perform the merge
> as soon
> as possible.
> This is true for Debian and likely any derivative around; it is also
> true regardless
> the init you use (runit, sysvinit or openrc).
>
> Stive Litt wrote :
> > I'm pretty sure if worst came to worst you could install runit by
> > the old ./configure;make;make-install route, and it will work just
> > fine with or without the merge, forever.
> right now, it really won't work
>
> Svante Signell wrote :
> > Hopefully your system will continue to work fine without usrmerge.
> Sadly, no
>
> Let me try to better explain this:
> Mitigation M2 in
> https://subdivi.de/~helmut/dep17.html
> means that *every deb package* is about to ship files directly in
> /usr/bin instead of /bin, or directly in /usr/lib instead of /lib and
> so on.. An unmerged system will end up *without* /bin/sh,
> /sbin/init, /lib64/ld-linux-x86-64.so.2
> (on amd64) just to make few relevant examples.
> At the end of the process (expected around March 2024) an unmerged
> system will have /bin, /lib, /sbin directories empty: but I doubt the
> system will be able to
> perform upgrades to that point.
> This move is *mandatory* for every Debian package, so until some
> derivative starts to support unmerged layout by forking 500/1000
> packages (or by some other means) the unmerged layout will be broken.
>
> Hope this helps to better understand the situation,
> Lorenzo


..all this means, is we need to ditch Debian as upstream for
everything important that touches /bin, /lib, /sbin etc that
we still need to boot or maintain our systems.

..the idea seems to be defeating Devuan etc people who are
serious about staying in whatever Debian-based business we
were running when this systemd mess hit Debian.

..common user apps that lives in /usr/bin etc is no problem,
even if they fail, they will not block boot-ups.

..we don't need or want any systemd shit in Devuan. Do we
still need all the "forking 500/1000 packages"?


..another means to keep the unmerged layouts unbroken, is
fetch and convert e.g. Slackware packages with e.g. alien.


> P.S.
> Note that runit is only acting as a messenger here: as runit
> maintainer supporting
> unmerged system is out of scope (and not feasible since for example I
> don't have
> control over /bin/sh) but failing to boot is a problem for the
> package. So I decided
> to print the message with the hope to be able to reach as many users
> as possible
> before the fallout.
> Even if the unmeged layout was declared unsupported, simply breaking
> systems with upgrades to the point where the user is forced to reset
> only to find
> out the the system will fail to boot - without any prior warning -
> does not seem a
> good approach to me..


--
..med vennlig hilsen = with Kind Regards from Arnt Karlsen
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.