I'm submitting the following *full* case on my own behalf.
Note that I'm not filing using the "normal" 20q format. I think this case
will be easier to understand without it. The major concerns raised in
this case have to do with our compatibility guarantees, which is why this
case must be handled as a full review. The content itself is fairly straight
forward.
I'm hoping to have a slot on the agenda for discussion on Oct. 21, 2009.
Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
EOF of libucb
1.2. Name of Document Author/Supplier:
Author: Garrett D'Amore
1.3 Date of This Document:
08 October, 2009
4. Technical Description
EOF of /usr/ucblib
------------------
We have already removed Source Compatibility for legacy SunOS 4.x (BSD)
applications. Right now we retain some of the infrastructure to support
legacy applications at *run-time* in the form of these libraries located
under /usr/ucblib (with both .so and .so.1, and 32 and 64-bit variants as
appropriate):
libcurses
libdbm
librpcsoc
libtermcap
libucb
Its our belief that these libraries should not be used in any applications,
even at run time. This is ancient, legacy stuff, best avoided by everyone.
There is quite a collection of advice to developers that these libraries
should be avoided, including in the man pages for the libraries themselves,
as well as numerous internet forum, mailing list, and usenet postings, spanning
a history well over a decade.
While this kind of removal is not normally appropriate for a "minor" release,
the unique rules surrounding the release of OpenSolaris (and subsequently
Solaris.Next) makes this seem a particularly good opportunity to finally
ditch this bit of baggage from the 1980's.
RISKS
-----
The main risk is that some software out there might still be using these
libraries. This would be particularly unfortunate, since those applications
will cease to function. A web search found only one common case, which is the
Mplayer and associated ffmpeg open source video player, where this was found
to be an issue. (In this case, a recompile of the open source application
without /usr/ucb in the compiler/linker search paths resolves the problem.)
MITIGATION
-----------
Fortunately, for applications that might have this problem but which
cannot be recompiled (such as when source code is not available), we do have
a mitigation strategy. The delivery of S10C (PSARC 2009/253) will make
it possible to use these applications in a legacy Solaris 10 container,
which will still have the /usr/ucblib libraries.
Its possible therefore that the Members might decide to insist that
this project not deliver before the S10C project does.
Its worth mentioning that this mitigation strategy is not perfect, since the
S10C project does not necessarily support all applications.
However, we believe that the S10C project will cover the bulk of any
applcations that need this kind of support, and we truly believe the number
of such applicattions to be vanishingly small.
COMMANDS IN /usr/ucb/
---------------------
One possible concern is our own commands that are delivered in /usr/ucb.
The project team has undertaken the effort to investigate these further.
All of them have now been converted (in a local workspace) to use safer
modern SYSV libraries located in /usr/lib ... with just a couple of minor
exceptions.
reset and tset use libtermcap in ways such that the terminfo replacement
does not provide equivalent functionality. While we believe that these
utilities should be converted to use native terminfo instead of termcap,
it turns out that it is simply more expedient to link a private copy of
libtermcap statically against these two utilities. Updating them to use
terminfo should be the subject of another effort, with a separate CR.
The remaining commands are the plotting commands, which the project team
is hoping to EOF separately per PSARC 2009/540.
With these changes, we no longer have a need for any of these libraries
to build our own software.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: OnePager
6.6. ARC Exposure: open
