Linux Emulation Lair

Public

• Join Room

Okay, let's test this thing.

It may be unfortunate but packages have to run commands on installation sometimes and for Linux packages these may be Linux commands requiring Linux compatibility. These are taken from the RPM that we repackage. Usually these commands generate some sort of cache, like the ld.so cache or the fontconfig cache, etc. In general we cannot guarantee that packages work correctly if these caches aren't there. So I prefer that we require or at least suggest that Linux compatibility be enabled before installing Linux packages. Now for the specific case of linux_base. It runs ldconfig and gio-querymodules. If ldconfig fails that's ok, because the run-time linker can still find libraries by searching the library path. If gio-querymodules fails that's fine at the moment, because we don't have any ports that install GIO modules, but it's not unthinkable that we might one day. Having a port of gvfs for instance would make it possible to access remote locations in GTK file dialogs. So for now it's fine if the commands fail, but we can't promise users it will stay that way.

What if linux_base installed an rc script, eg /usr/local/etc/rc.d/linux_base, which contains the commands above, conditional on linux_enable being set, and with DEPENDS: linux? You could also have a file created on installation and upgrade time somewhere under /compat/linux/var, that would be removed on the first run of that script.

If the commands fail on package installation then they should run when the user runs service linux start. That doesn't happen with a linux_base rc.d script does it? I guess it would work if linux_base (and other Linux packages) installed a script in a location that is then sourced by /etc/rc.d/linux.

True, that’s even better.

Would it be possible for Linux_base to provide libaio and libnuma? Some of the LTP tests want those; even if we don’t provide the SysCare yet, this would be an useful first step.

I've submitted patches in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242981 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242982.

I've just tested them and it works, thanks!

FWIW, libnuma affects 64 tests, libaio - 12, libtirpc - 215.

libtirpc patch submitted in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242985

There's a version problem. Still, those tests are not run by default; libaio and libnuma are more important atm, I think.

Hi. So, given the libaio and libnuma ports seem to work, is theee anything left to do before committing them?

Do you use, or know someone who uses, an application that needs them? I always ask this question when adding new ports because if nobody uses a port all the time spent on maintaining it is a waste.

Well, yes - LTP. Those libraries are a prerequisite to making several tests pass.

Ok, committed in https://svnweb.freebsd.org/changeset/ports/522476 and https://svnweb.freebsd.org/changeset/ports/522478.

Thanks! Does https://reviews.freebsd.org/D23104 look ok? I'm not sure that's the proper way to register dependencies.

Are there plans for linux c8? In ports, I mean.

No, I haven't looked into yet.

Do you know of anyone working on improving the "userspace bootstrap", so to speak?

No. The question comes up sometimes but I always thought yum and pkg would interfere with each other too much, overwriting each other's files on upgrades. It just looks like it could easily become a support nightmare. For me the linuxulator is meant to run binary-only commercial Linux software. Most of these are almost fully self-contained requiring only a minimal set of dependencies. If any such dependencies are missing we can add them to the ports tree. They also require only a minimal set of kernel features. If people want a full Linux distribution a virtual machine with a real Linux kernel seems better suited. Anyway, this is just my personal opinion. I've been getting less involved with FreeBSD lately so I don't want to make decisions about what direction to take. If the community wants yum then go and add yum. I would just first ask them what application they are trying to run that makes them think they need yum and then see if I could get the application running without it. Limiting the scope of the linuxulator is what keeps it manageable.

Okay, I think I agree. How about adding a port for eg debootstrap, so that the full linux distro could be bootstrapped into eg /compat/ubuntu? The reason is, first, it makes experimenting with Linux stuff much easier, and second, it makes it easy to create Linux jails.

I'll try to compile a list of dependencies neccessary for debootstrap.