Re: Building a Linuxulator userland from source

It would be nice to try that tool that can hack / convert ./ add another
layer (another linux distro inside the first one. I dont remember the name
now.

Il mer 23 ago 2023, 08:21 Felix Palmen <zirias@freebsd.org> ha scritto:

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