Am 2023-08-18 11:26, schrieb Felix Palmen:
Hi Alexander,
thanks for commenting!
* Alexander Leidinger <alexan...@leidinger.net> [20230818 11:02]:
As the person who switched the linuxulator from redhat 4 or 5 to
fedora and
mentored the people which moved forward to linux-c6 I have some info
about
the design principles of the linux_base ports which you may or may not
know
already:
https://www.leidinger.net/blog/2011/08/29/howto-create-a-new-linux_base-port/
https://www.leidinger.net/blog/2011/09/01/howto-add-linux-infrastructure-ports-for-a-new-linux_base-port/
This might certainly be useful to check against. I think I do have some
understanding, but so far only from looking at what existing ports are
doing.
If it shall not be much of a moving target, I associate "not much
work" with
it. This is somehow contradicting your approach with building from
source in
my opinion. It also opens up the question if any issue is because of
what we
do with it, or because of upstream. And this additionally to the
complexity
if the issue is in our linuxulator (kernel side). This doesn't sound
much
like "not much work".
Yes, I see how "bug hunting" could be an issue. So far, I could stay
*very* close to upstream in my ports, but yep, it's only the GNU
toolchain, I will have to see where it leads.
> - Provide the newest GNU libs (glibc, libstdc++, ...) built against
> exactly the Linux version emulated by the FreeBSD version this will
> run on. This should make it possible to run a lot more Linux binaries
> without relying on e.g. Linux jails.
I see a mismatch here. You want to have the newest ones, while the
distribution itself shall not be a much of a moving target.
This seems to be a misunderstanding though. IMHO, for repackaging some
distribution, this should not be a moving target, because otherwise you
could have some unpleasant surprise like some glibc update suddenly
requiring a newer Linux version that the FreeBSD kernel offers.
With building from source, at least *this* can't be a problem, because
the base libs will always be built with the "correct" version of the
Linux headers.
> - When binaries don't work for missing Linux libraries, make it somewhat
> easy to add them, maybe based on already existing FreeBSD ports.
This may be harder than you think. Or more easy than I think. The
FreeBSD
ports will have stuff specific to FreeBSD which may not be needed for
the
linux-on-FreeBSD-build. The building part may involve more hackery
than the
FreeBSD port.
Yes, I'm aware of that. It might require quite some work on the
framework to make it actually easy. TBH, this is just an idea so far, I
didn't really think about come concrete concept yet.
USE=linux is suited for the needs of a linux_base port. A linux_base
port is
designed to integrate with the FreeBSD system (= fallthrough so
FreeBSD
config if the config is a drop-in replacement for the linux config,
e.g.
krb5.conf or hosts and such). What you need for building is on the
other
hand a "pure" linux system without any fallthrough to FreeBSD, to make
sure
you don't pollute the linux-build with FreeBSD stuff. This means at
least a
chroot into some linux_dist-style port instead of a linux_base style
port.
1.) Of course, Uses/linux.mk would need quite some switching to handle
c7 as well as something new that works completely differently (maybe
call it src). All still open issues.
I suggest to write a new Uses/xxx.mk for this. Much more easy for you to
do what you want, and less error prone and less QA to do for the
existing linux_base stuff.
2.) Could you please elaborate how e.g. some config file "visible" to
the Linux processes could "pollute" a Linux build? Besides, this could
only affect files from base /etc I think...
Well... the config part was more to highlight what the linux_base ports
use the fallthrough for. In case of building I worry more that some
includes from /usr/local are used than anything else. Also some other
stuff configure-runs might pick-up from the installed FreeBSD ports.
Bye,
Alexander.
--
http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org netch...@freebsd.org : PGP 0x8F31830F9F2772BF
