Guidance for using Lima as dev machine

[jchimene]

It looks like it's not advisable to map similar directories between MacOs and Linux when using Lima as a staging tool for production. I had particular failure around /var
The advantage of mapping is that I could use the same directories to test under Linux and MacOS. That's not possible wiithout sharing.
For example, mapping /var/cache in Lima didn't work w/r/t installation via dpkg, same with /var/www
All attempts were failures. It wasn't until I realized that such sharing won't work given the MacOS file protection framework with respect to dpkg --install ; during which process a file's ownership can be set to root:root in a Linux-only directory
The use case is to create a dev box to test Debian dpkg work before deploying to production. Once I stopped mounting the shared directories, I got a deployable build via the Debian dpkg framework.
I'm not looking for Debian support. I think the same issues would apply if building rpm. I apologize for this poorly worded question. I'm trying to understand if earlier failures were due to MacOS file protection in shared directories or my inexperience with Lima.

This dpkg install also involves changing file ownership which I think was frustrated by mapping group ids between MacOS and Linux. After reading further, I think part of the answer involves startup scripts to establish group membership during the boot process.

[afbjorklund]

For shared network filesystems - as is common with for instance NFS - it is best to avoid known local locations like /var

Lima is not yet working fully with a shared home directory, so prefers to use a local home and /tmp/lima for exchange.

[afbjorklund]

When I used to this, we used tools like pbuilder or mock do this (with chroot). Maybe those would make nice lima examples ? Similar to the current example for BuildKit, but for producing .deb or .rpm instead of container images.

• https://wiki.ubuntu.com/PbuilderHowto
• https://fedoraproject.org/wiki/Using_Mock_to_test_package_builds

[jchimene]

I've left quite a bit out to simplify the issue to the bare essentials. Your last sentence is where I now find this project; which has need of a newly uncovered nginx debug step. I was quite annoyed when the nginx conf files from MacOS failed when deployed to Linux (which is where sharing /var started). Now I have to work on this nginx conf file under Lima; while trying to understand how Lima forwards network connections. I think I have it mostly figured out, I'm just annoyed that I didn't get the nginx issues sorted sooner.

I didn't need to run nginx+php under Lima during the earlier work. I could run the server side on MacOS: launchd + nginx + php + Rust. Lima just hosted the dpkg toolset. As I got farther into the dpkg installation steps (from dpkg creation), I moved to spending more time in Lima than MacOS; where this particular episode began with the file sharing observation. Now Lima will be more of a debug tool for this nginx conf file failure.

Further context: I've been using Debian since Potato. It's only in the past year that I find myself on MacOS, and in the past month learning how to build deb files.

[jchimene]

re: pbuild & mock

You're building far more complex packages than I. Which is not to say the build requirements for this project are simple; they're handled by Rust's Cargo tool, not debian descriptions that need the muscle provided by pbuild or mock.

It turns out the heavy lifiting for this build can be handled by a Rust library for Cargo called "cargo-deb". It has some rough edges, but for simple projects like this, it quite fits the requirement.

I decided after this major version upgrade to adopt dpkg for repeatibility when deploying to production. The new nginx location is part of this version step. Always one more last-minute issue....

[afbjorklund]

You're building far more complex packages than I.

It was mostly for rebuilding distribution packages. These days, I normally use nfpm when packaging software.

[jchimene]

That's exactly what cargo-deb does, but only for debian. In that case, it reads the Cargo.toml for those debian fields. I can see why nfpm would be a better choice for multi-distro builds. It looks like it needs debian/rules; which for my purpose I've stopped using since starting with cargo-deb