gh-127072: Remove outdated socket.NETLINK_* constants.
#127256
Conversation
|
Personally, I believe that the main branch should support the latest features. If users need to use them, they can opt for previous releases rather than building from the main branch source code. Moreover, the feature support for operating systems should not be deprecated, as they may be removed at any time due to performance issues. WDYT? |
|
I should summon another OS enthusiast, listen to his opinion. cc @zooba |
|
I'm not too sure what your point is. We're not supporting anything new--we're just removing support for some macros, which have very little maintenace burden anyway. I'm not opposed to removing them if they aren't available on any system that Python can be built for, because then we're just getting rid of code clutter, but I want to be absolutely sure before we do.
Rant aside, that's not encouraging. Ideally, we want people to migrate to new versions, not brush people off with "download <3.14 instead if you need to use that."
Sure, but we're a wrapper over OS features--we'd be deprecating our wrapper for a feature, not the feature itself. |
I'm almost sure that it doesn't exist in the main branches of Linux and freeBSD. So my current idea is to wait for zooba answer. I'm not sure whether there is a compatible system similar to netlink in windows. Edit So my point is that if there is a compatible system in Windows, then I will turn off this PR. If it does not exist, then this PR can be merged, because we don't need to maintain some macro packages that do not exist. |
Great, but we support more than just their current main. I get that these macros aren't on modern systems, but what about the older versions that we support? Will we give a nasty surprise to them with 3.14? I'll yield to Steve, but I doubt he'll be in favor of dropping support for things without checking to make sure that nobody is using them. |
Yes, that's what I'm worried about, so the PR is a draft. I'm not sure if there is a cpython that migrates the old-system to the main branch. |
|
I searched through Linux kernel sources for these. The most recent version of Linux that included any of these constants was 2.6.17, which was EOL in October 2006. I don't know how much of an afterlife Linux kernel versions have after EOL though. |
There was a problem hiding this comment.
I searched through Linux kernel sources for these. The most recent version of Linux that included any of these constants was 2.6.17, which was EOL in October 2006. I don't know how much of an afterlife Linux kernel versions have after EOL though.
This is the way to approach this kind of change. Thanks.
It is fine for us to drop support for an 18 year old kernel. (anything that is still within the kernel SLTS/CIP window is worth continuing to support)
I confirmed your greps by spot checking 2.6.18 and a 4.20.17 kernel source. These constants are long gone.
In general though, this kind of change has little value. So rather than spend time doing this kind of sleuthing we just let the no-op ifdef'd things sit around. It is highly annoying if we ever get this wrong as people have to adapt by manually defining the constant in their code, at which point they trust us less.
|
Thanks for the merge of @gpshead. Here, I know a new OS enthusiast :) |
…nGH-127256) Remove seriously outdated netlink constants. Co-authored-by: Gregory P. Smith <[email protected]>
socket.NETLINK_*constants #127072They have been removed from the linux master branch, but I'm not sure we need to sync with master (this would be a problem for older systems that would not be able to use the removed constants when built from cpython master source).