Mark Millard

> Because I use packages stored in a local media. Normal repositories can be on local media and handled in normal upgrade and install ways. For example I use: ```...

> Another problem that I found empirically: the BACKUP_LIBRARIES mechanism doesn't work with split package upgrades, where we deinstall the old version and install the new version as separate steps....

> I understand what you are trying to do, and the will behind, I am just saying that I have no idea how to make it happen in pkg in...

Suppose the ports tree recently updated to have rust 1.89.0 (many ports are updated to requires/use 1.89.0 when rust is updated) but the most recent binary for downloading is still...

> This should be fixed by the new incremental build. It's off-by-default because it can cause some surprising behavior, and I need to do some writeups on it to make...

> So, coming back to this issue, it feels like a Discussion. Can I convert it to that? I certainly have no reason to object. But I'm not primary here.

[I will note here that pkg conventions are also involved here, not just poudriere ones.] FYI: `poudriere jail -c -jgenerator -aaarch64 -U https://pkg.freebsd.org -mpkgbase=base_latest -v 15` works by finding: `https://pkg.freebsd.org/FreeBSD:15:aarch64/base_latest/`...

> Debug log (5MB) from installing `ebsnvme-id` into the lib32-free system mentioned above: > > [debug.log](https://github.com/user-attachments/files/22731079/debug.log) Lots of references to various gcc*'s having libgcc_s.so.1:32 --and having other :32 references :...

Notably, aarch64 would also have such references if the ports enabled MULTILIB like is done for amd64. As fas as I can tell, the ports should have MULTILIB enabled for...

I see that pkg still mis-identifies lang/gcc* as dependent on base packages instead of the content that the lang/gcc* installs that should be used via -Wl,-rpath= based on paths tied...