This is the mail archive of the
mailing list for the glibc project.
Re: PATCH: Add x32 dummy sysctl
On Tue, 22 May 2012, Carlos O'Donell wrote:
> For example:
> Step 1. During X.Y-1 announce to distro maintainers the list of API
> functions we are deprecating in X.Y, and ask for feedback.
> Step 2. Mark the API deprecated in X.Y.
> Step 3. Remove the API in X.Y+?, but leave it in the ABI.
> Step 4. Remove the ABI in X.Y+?
There's a general page about deprecations:
<http://sourceware.org/glibc/wiki/Deprecation>. In technical terms:
To deprecate an interface to the shared libraries, you arrange for it no
longer to be available for newly linked programs and shared libraries,
only previously linked ones, as was done for the RPC code. At the same
time, you remove it from the headers (I don't think there should be an
intermediate stage when it's available for linking but not in the headers,
or vice versa). Unless it's needed internally (like the RPC code), you
also arrange for it not to be built at all for architectures whose minimum
symbol version is sufficiently new.
(What would the versions for the RPC symbols look like for an architecture
with GLIBC_2.14 or later as minimum version? I suppose that without
--enable-obsolete-rpc the symbols would be present at the minimum version,
but not available for linking against. Only if we eliminate the need for
the symbols to be used internally, maybe arranging for libtirpc to be
dlopened as needed once it has all the required features, could we then
set a later version as the one such that if the minimum symbol version is
that recent then the code isn't built in at all.)
Perhaps someone familiar with the relevant symbol versioning mechanisms
could write up something for the wiki about how to make a symbol not
available for new programs, and how to make it not available at all if the
minimum symbol version is new enough?
If what you want to deprecate is purely in a header rather than affecting
the shared libraries: technically you just remove it from the header (with
whatever notice may be appropriate). I think any general policy regarding
*what* to deprecate needs to be discussed here (and so we should close bug
13959 as INVALID; Bugzilla is not a suitable place for general policy
questions as opposed to specific deficiencies).
Joseph S. Myers