Re: Building a Linuxulator userland from source

* Cy Schubert <Cy.Schubert@cschubert.com> [20230822 10:34]:
> Basically this would become another Linux distro, albeit a virtual one
> that runs under our Linuxulator.

And also a pretty minimal one. Right now, I'm just building a truly
minimal userland (the GNU toolchain, openssl, GNU make/grep/sed/awk, GNU
coreutils and man-db) and working on putting together some sane USES for
that.

> Avoiding discussion about packaging -- we can package this any way we
> wish -- how will this support software written for distro A, B, or C.
> For example, Red Hat software doesn't neccesarily run on SuSE or
> Ubuntu because shared library dependencies may be different.
> 
> Building our own "distro" to run under the Linuxulator may require a
> complete set of packages and end-user applications because existing
> Linux software may require a Fedora, Debian or Red Hat library.
> Wouldn't this negate the need for a Linuxulator because a person can
> build most Linux software to run on native FreeBSD.

Well first, when I ask why "Linuxulator" is needed, the answer in my
head is: Mostly for closed-source Linux software. Because exactly as you
say, anything else should better be ported and built to run natively on
FreeBSD, if possible.

Now, maybe I'm looking at the wrong software? In my experience with
closed-source Linux Software, sure, it *might* offer
distribution-specific packages, but almost always offers a plain binary
tarball as well. The latter could easily be used to create a port (like
was done in the past as well in our tree), and then it's just a question
of adding ports for the (hopefully few) shared libraries needed by this
software.

> I think a better path might be to support multiple Linux userlands in
> parallel. Thus a user could simply copy or install vendor software for
> a Red Hat in one environment and a SuSE vendor software in another.

This would be the consequence if you really want to support
distribution-specific software packages. I don't think it's feasible in
practice, at least it would make it very hard to still have ports of
Linux software (like my makemkv port), these would need to build and run
with any of these userlands.

To challenge my source-based approach, I'm looking for "proof of
concept" closed-source software to try get running with it, I'll
probably start with makemkv because I already maintain that port. Open
to suggestions what else to test there. In the end, getting to run e.g.
Google Chrome would be perfect, but I imagine this requires creating a
lot of ports for shared libs first.

Cheers, Felix

-- 
 Felix Palmen <zirias@FreeBSD.org>     {private}   felix@palmen-it.de
 -- ports committer --                     {web}  http://palmen-it.de
 {pgp public key}  http://palmen-it.de/pub.txt
 {pgp fingerprint} 6936 13D5 5BBF 4837 B212  3ACC 54AD E006 9879 F231