Tue, 28 Nov 2023 00:37:50 +0100 - Lorenz via Dng <dng@???>:

> I'm sharing infos in the hope to save some time to people interested
> in supporting unmerged layout on Devuan.

Initial clarification: usr-merge seems like a huge bullshit to me, the
reasons for which are laughable to say the least, particularly considering
the "cost" it determines.

Another premise: in my Daedalus ws, with 2849 installed packages, I have:

$ tree /bin | tail -1
1 directory, 157 files

$ tree /lib | tail -1
3578 directories, 16760 files

$ tree /lib64 | tail -1
1 directory, 1 file

$ tree /sbin | tail -1
1 directory, 244 files


> 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.

In both cases (plus non essential/required programs), a very large number
of files/directories would be involved to manage the symlinks or manage the
forks...
A notable effort, which should be maintained constantly over time...
Debian could... Devuan can do it?


> 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!

Unless a simple solution is found, once and for all, that can be stable over
time without requiring heavy (and above all continuous over time) development
activities... perhaps the "realistic" possibilities for Debian derivatives
are to surrender to this usr-merge-idiocy or to change upstream distro...

I think this because Devuan has few development resources, which perhaps would
be better spent on the "init" side, given that Debian will end up dropping
sysvinit, and then Devuan will need to be ready with an alternative init...

Regards
alexus


--
Property is theft! (P-J Proudhon) -- True today more than ever.
______________________________________________________________________

Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8 B624 DA50 835B 2624 A36B