Re: the case of untracked base shlibs

On Tue, May 12, 2026 at 9:42 AM Sulev-Madis Silber <
[email protected]> wrote:

> oh, hell, guys, it works
>
> can you name reasons why mixing ports is bad?
>
> there's binary compat for a reason. one could say that's an abuse but does
> it matter. iirc binary compat goes back to 4.3 bsd. anyone have pre fbsd 1
> binary running still? i'm curious!
>

We try super hard for binaries in base to retain compatibility. For ports
we don't try at all. so mixing ports from different eras produces lots of
different conflicts. Some specific subsets of ports can be 'cross threaded'
like that, so long as they are a self-contained set that only links to the
base.


> i also have "consistent" 16 kernel 16 userland 13 ports which was created
> because user qemu only goes down (why?) on versions, not up. this needed
> shlibs symlinking to work, tho. openssl again
>

user qemu is stuck at 3.2. But sometimes people install the 'devel' version
that's something higher. The devel version has been that way for a long
long time because we've not been able to get it stable for a variety of
reasons (some of which are my fault).

Warner


> i bet many have custom systems which they share. sometimes this could get
> official because os is for users eh
>
> the main reason for that scan was what to rebuild first. that could be
> important if you upgraded running system that way
>
> btw, when is arch a "*"? when there are no platform specific binaries in
> package? but there seems to be
>
>