Hi Lorenz,
Nice posting, comments below.
(Can you please use plain text instead of html mail so replying will be
easier in the future. Thanks!)
On Tue, 2023-11-28 at 00:37 +0100, Lorenz via Dng wrote:
> Hi all,
>
> I'm sharing infos in the hope to save some time to people interested
> in supporting unmerged layout on Devuan.
>
> First thing: at the end of this usrmerge transition, the usrmerge
> package is expected to go away and the essential package "base-files"
> is expected to ship /bin /sbin (and so on) as symlinks.
> So, I think, the first step to support a unmerged layout is to fork
> "base-files" into something like "base-files-unmerged" that Breaks
> and Replaces the official package. While the forked package installs
> /bin /sbin and so as directories the system becomes broken, so the
> package need to do some symlink farming. I think this can be done by
> having a postinstall script that uses perl as interpreter. This
> symlink list should guarantee that essential functionality of
> the system works, including boot and shutdown.
>
> at this point there are at least two options:
>
> A) continue with symlink farming approach:
> create a symlink for each program that is expected to be
> available in /bin. for example /bin/foo would be a symlink to
> /usr/bin/foo I'm not sure people that feel strong against usrmerge
> will see a value in this setup ( /bin and /sbin filled with symlinks)
> but there are advantages: * only one package is forked
> * deb packages no longer need to obey to restrictions listed as
> mitigations in https://subdivi.de/~helmut/dep17.html
> (while Debian will need to obey the list forever)
> * you can have extra packages that install stuff in /bin /sbin
> Still separate /usr layouts need to boot via initramfs and a list of
> non-essential programs that needs symlinks has to be maintained.
>
> B) on top of "base-files-unmerged", fork other packages:
> I don't have the exact number, but I recall Helmut writing about
> 500 packages involved (because of systemd units) that are about
> half (or maybe 2/3) of the problem, so I think the number rages
> from 750 to 1000 sources. However, 500 are involved because of
> systemd unit (and we don't care about these) so the number can be
> as low as ~250.
> Anyway, if one focus on the essential set the number shrinks to
> something like ~40 packages, and another ~40 with priority important.
> Not necessary all of those 80 packages need to be rebuilded.
>
> regardless that A or B is chosen, there is another problem: with the
> merged layout it doesn't matter if one calls /bin/foo or
> /usr/bin/foo, but with the unmerged one it does; so B) may need to
> create symlink for essential+important binaries under /usr.
> And both A and B will need to create and maintain a certain number of
> symlinks for non essential/required programs that are invoked with
> the "wrong" path; the number of such program is unknown and may
> increase in future.
>
> Please keep in mind that the above is just a draft, I have not done
> any test to ensure that it really works. I don't have the time and
> energy to continue this work right now, but I may have in the future
> so if anyone starts working on this, please keep me in the loop!
Thanks, a very constructive posting. I'll vote for B) even if there is
more work to make it happen. Keep the ideas flowing!
Thanks!