[PATCH] Linux: Remove <sys/sysctl.h> and the sysctl function
Adhemerval Zanella
adhemerval.zanella@linaro.org
Thu Mar 12 14:33:14 GMT 2020
On 12/03/2020 05:15, Florian Weimer wrote:
> * Vineet Gupta via Libc-alpha:
>
>> On 3/11/20 1:19 PM, Zack Weinberg wrote:
>>> So I withdraw my objections to your original patch. We can always put
>>> sys/sysctl.h back in the future if someone does the work to write the
>>> emulation.
>>
>> My 2 cents. Can we _not_ remove the header per-se. This can certainly cause
>> arbitrary packages to build time fail (vs. runtime failure from sysctl returning
>> -1 or some such). Propagation of such fixes in build systems it may take a while.
>> Consider my personal woe with stime removal in context of Buildroot/busybox.
>> Despite them fixed in busybox not all moving parts are aligned still and we have
>> to carry such patches locally to be able to even build glibc 2.31+ there.
>
> Why aren't those patches upstream yet? (I'm not blaming you, I'm just
> trying to understand what is going on.)
>
> Are you in a special position becaue you have to use a newer glibc for
> your port, and everybody else using this distribution is sticking with
> an older glibc?
>
> glibc's approach to removals is inconsistent at best. stime was never
> deprecated and removed directly, for example. There is also the issue
> that configure scripts ignore deprecation warnings, which then can
> lead to build issues later one, something that does not happen with
> removed interfaces (which are obviously not detected by configure
> scripts).
stime removal was done without deprecation mainly because it has
been an obsolete function for a long time and it would not make
sense to make a y2038 safe version of it. Since y2038 was not done
for 2.31, maybe we could instead instead had mark it as deprecated
remove it on 2.32 (along with the header).
>
> And specific to sysctl, the removal of the header and function
> actually fixes bugs in a few packages.
>
It is always a risk to remove an installed headers and for this
one specifically I agree with you, it is time to move forward
and stop providing it.
More information about the Libc-alpha
mailing list