This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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+?
> Comments?

There's a general page about deprecations: 
<>.  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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]