On Tue, 28 Nov 2023 00:37:50 +0100
Lorenz via Dng <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.
Hi,
I fail to understand this symlink solution:
if the problem is that you cannot have a separate /usr
directory which could be or not on a separate partition
where would your symlinks point to when the separate
/usr partition is not yet mounted?
Not that I fully understand the implications of usrmerge,
but I see multiple problems that could not be fixed by one
solution:
1) first problem is if I am conservative and don't like usrmerge and want to keep
things as they are probably this will be an uphill run until capitulation.
2) usrmerge breaks my setup (e.g /usr on separate partition, there sure
are other cases I am not able to imagine), in this case I would like to ensure
to be able to boot my system (to fix the fallout ( and maybe do the usrmerge))
What would I try for case 2 (absolutely untested with high bullshit risk) :
1) try to identify what binaries are needed to boot my system (could be different depending on setup?)
2) create /bin /sbin dirs in /
3) populate /bin /sbin with static! binaries of the programs needed ( maybe just
a static linked copy of busybox could be enough) so we need no libs and no dynamic linker
4) boot the system to the point /usr is available (mounted?!) and populated
5) hide my tracks and make the system debian compatible again
mount --bind /usr/bin /bin
mount --bind /usr/sbin /sbin
.... (are more needed?)
6) ensure this mess is correctly untangled at shutdown
( is umount -a enough?)
Has this beer originated idea any chance to work I doubt it.....
Just my 2 cents.
Ciao,
Tito
> 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
Isn't PATH there for this? paths to binaries shouldn't be hardcoded.
> 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!
>
> Cheers,
> Lorenzo
::
Re: [DNG] Thoughts and infos on unm…
