On Fri, Dec 19, 2025 at 12:18:04PM -0800, Gleb Smirnoff wrote: > On Fri, Dec 19, 2025 at 09:57:17PM +0200, Konstantin Belousov wrote: > K> We are discussing different things altogether. > K> > K> I am saying that you are breaking binary compatibility, and asking why. > K> I do not see a reason. > K> > K> It has no relation to the fact that there are other ways to get the same > K> behaviour from the system. The removal of that three lines breaks existing > K> binaries. Also it does not matter that e.g. newer versions of some apps > K> do not use that feature (feature as in binary interface, not a system > K> behaviour). The existing binaries must continue to work. > > We already have had this argument before for a different kind of issue - > POLLINIGNEOF. The existence of such binaries is like existence the the God. > You can't prove they exist. I can't prove they do not exist. You advocate for > the compat shim to exist forever. I advocate to limit it existence to some > countable number of years. > > For this particular case all open source software had been addressed. There > are no known shareware binaries in the wild that used AF_INET/IPPROTO_DIVERT. I do not understand this statement. It was demonstrated in this thread that python had it.
> Those hypothethical binaries that we can't prove/refute existence of in some > corporate environments would print a warning on 14.x and on 15.x providing a > time to their owners to recompile. If we speculate that somewhere in the > universe exists a corporate body that uses AF_INET/IPPROTO_DIVERT tuple in > their internal software and have lost its source code, they have a solution. > The solution is a tiny preloaded library that would intercept socket(2). Of > course you may say that somewhere in the world exists a closed ecosystem that > uses AF_INET/IPPROTO_DIVERT in a binary AND the sources for the binary were > lost AND the binary is statically compiled. If you decide to go that deep > into > the rabbit hole, I would reply that owners of such a binary should bit hack it > to use the correct tuple before call to socket(2). No. You abruptly break binary compatibility and claim that this is fine. It is not.
