The following fast track (submitted on my own behalf) straddles (IMO) the
boundary between a full-case and a fast track, primarily because of the
impact it has on what are presumed to be Committed interfaces.
It seems fairly straight-forward to me, but other members may feel otherwise.
With that in mind, if a member feels discussion or an explicit vote is
required, please don't hestite to derail it. I've also used a two-week timer
to ensure that sufficient time is given for members to review and derail if
that is appropriate. Thanks.
- Garrett
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 plotting components
1.2. Name of Document Author/Supplier:
Author: Garrett D'Amore
1.3 Date of This Document:
07 October, 2009
4. Technical Description
EOF of plot, graph, lpr -g, and related legacy
----------------------------------------------
As part of my analysis of UCB legacy we can potentially clean up, one of the
items that came up is the support for legacy plotters via the plot(4B)
file format, libplot, graph(1), and the various /usr/ucb/ plotting commands.
It turns out that these bits are used to support physical devices which are
no longer readily accessible, and probably have not been so in quite a long
time. (These devices largely date back to the 70's, 80's, and early 90's.)
Modern devices use PostScript or HP-GL/2, neither of which are
supported by the current Solaris plotting infrastructure, but are well
supported via the same infrastructure used to support ordinary printers.
There is also support for plotting to a terminal device, either a graphics
or a text based terminal. The graphics terminals that are supported are
quite ancient (although "xterm" can emulate a Tek 4013 device), and the
project team feels that the plotting support for character
based terminals is of rather limited use.
Note also that users who might still have such ancient hardware (or want
to plot to a terminal device) might find they are able to plot to it using
the "gnuplot" command, which has output drivers for it. (Gnuplot is not yet
integrated, but this is expected as it was approved as part of PSARC 2009/395.
If the PSARC members feel the rest of this case warrants sufficient risk
to justify it, this project team is willing to accept delivery
of PSARC 2009/395 as a pre-requisite, although we don't particularly
feel that it should be so.)
Proposal
--------
1) We propose to entirely remove all of the plotting commands from
/usr/ucb. This consists of
/usr/ucb/aedplot
/usr/ucb/atoplot
/usr/ucb/bgplot
/usr/ucb/crtplot
/usr/ucb/dumbplot
/usr/ucb/gigiplot
/usr/ucb/hp7221plot
/usr/ucb/hpplot
/usr/ucb/implot
/usr/ucb/plot
/usr/ucb/vplot
/usr/ucb/t300
/usr/ucb/t300s
/usr/ucb/t4013
/usr/ucb/t450
/usr/ucb/tek
We don't believe any applications will be impacted by this removal.
2) We propose to remove /usr/bin/graph. We believe this program is also
not terribly useful, since the only way to generate plotting output from it is
with one of the above commands, which almost certainly precludes being
able to get hardcopy. (And graphical display is probably limited to output
in an xterm tek window, for users with enough savvy to figure this part out.)
Note that gnuplot offers a vastly superior superset of graph(1)'s capabilities,
and is capable of processing graph(1) input files. (It would probably be
only a small task to provide a shell-script called "graph" that offered
the same command line switches as graph(1), but used gnuplot to generate
its output. The utility of this seems questionable, however, unless the
output format is changed from plot(4B) -- which gnuplot can generate -- but
which would also defeat any compatibility purpose.
3) We propose to obsolete libplot(3plot) and its brethren, but leave the
libraries in place for the benefit of applications which may have linked
against them in the past. (It is impossible to know what those applications
might be.)
The specific taxonomy changes are (note that no stability was ever mentioned
before for these libraries, so we assume Committed for this use):
/usr/lib/libplot.so.1 Obsolete Committed
/usr/lib/lib300.so.1 " "
/usr/lib/lib300s.so.1 " "
/usr/lib/lib4014.so.1 " "
/usr/lib/lib450.so.1 " "
/usr/lib/libvt0.so.1 " "
Note: Its likely that these libraries could be safely removed -- despite
the "Committed" level -- or replaced with stubs that simply resolve the
symbols but don't actually generate any output. We simply don't believe
any real programs use these libraries but we don't know for sure.
4) We propose to remove the "-g" option to /usr/ucb/lpr, which was intended to
support the plot(4B) format. Again, real devices which could benefit
from these filters are just not to be found in the modern era. Lpr would
exit with an error number if this option is supplied.
Note that /usr/ucb/lpr is already effectively obsolete, by virtue of being
delivered in /usr/ucb. Also, CUPS lacks support for this option, so
eliminating it will facilitate an eventual replacement of our legacy printing
stack with the far more functional and better-maintained CUPS implementation.
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
