On Tue, Nov 28, 2023 at 12:37:50AM +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.

I had a brief look. `apt-file show base-files | grep bin `
has no output on my (admittedly usrmerged) system.

Unless something is broken on the website, there are no
binaries in and bin or sbin directories in this package.

https://packages.debian.org/bookworm/amd64/base-files/filelist

Okay, I downloaded the package, it does contain empty /bin
and /sbin directories, which could be symlinks.

While I'm not sure about booting, and boot-related packages
such as runit, most packages will not see the underlying
file system, and naively traverse symlinks.

This means you might be able to use symlinks in reverse, that is,
having a farm of symlinks in /usr/bin and /usr/sbin pointing
to the actual files in /bin and /sbin. For this, before
every package installation (at least every one that touches
these directories or their usrmerge equivalents), you'd have to inspect the
installed files and ensure the corresponding symlinks are
present.

It's interesting to think about, but thinking can miss edge
cases. For example, what to do when new, boot-essential
programs appear in /usr/bin or /usr/sbin? How would you know
they should be physically present in /bin or /sbin and
symlinked to /usr/(s)bin.

I imagine there are likely to be a number of debian users
with remote boxen with separate partitions. Would those
users have spoken up? I wonder. Maybe worth checking the
debian mailing list archives. I could see one wouldn't want
to be stuck on an older version of Debian/Devuan because of
the this issue. OTOH, there are situations where even remote
boxen must be attended to, such as a failed motherboard or
disk drive. Needing a repartition would fall into this
category.

I would also want to ask debian developers, are partitioning
requirements going to change in future, or is this a
one-time alteration? Will I have to visit my remote boxen
again due to future changes?

One more thought. How much space do the files in /bin and /sbin
partitions consume? Could they be simply copied over to /usr/(s)bin and
appropriately symlinked. But then how could one create symlinks
on the mounted directory? You'd still have to visit the
box and boot from a rescue disk/partition in the final step.

Those are my (inflation-depreciated) 2c. Hope a solution
can be found.



> 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!
>
> Cheers,
> Lorenzo

> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


--
Joel Roth