In the absence of feedback, I've decided that the best approach is to
leave the functionality that is potentially still useful, and remove the
functionality that is not. I'm doing this as an update to this case; I
don't believe restarting the timer is necessary. Here's the actual changes:
1) Remove the /usr/ucb plotting commands, as indicated.
2) Leave graph and lpr -g alone for now.
3) Leave any other commands (posttek, postplot) alone for now.
A future case will be necessary if /usr/bin/graph, or any of the other
stuff (outside of the /usr/ucb commands) that deals with plot(4UCB) is
to be removed.
Personally, I believe the time is ripe to eliminate that stuff, but I
don't want to broaden the scope of *this* case without properly
reviewing it. I'll file a separate case to do that later.
- Garrett
Garrett D'Amore wrote:
>
> So, in the process of going about the work to remove these utilities,
> I found a few surprises.
>
> First off, it is possible to take "graph" output, and generate
> postscript, using the "postplot" utility (located in
> /usr/lib/lp/postscript).
>
> Second, it turns out that there are other postscript filters related
> to postplot in some way, but which possibly could also be removed as
> they are unlikely to be found useful in modern systems. (I'm
> speaking specifically of posttek and postdaisy, which convert Tek 4014
> and Diablo 630 format files into PostScript.)
>
> What isn't clear to me here is what the best approach is. Some options:
>
> 1) Decline to remove "/usr/bin/graph" at this point, and remove it
> only later when/if we find we can remove the postscript commands.
>
> 2) We could also leave the "-g" option in LPR, although I think its
> better to remove it since CUPS can't support it.
> 3) We could remove "postplot" (which mostly exists for the purpose of
> dealing with "lpr -g"), as well.
>
> 4) We could decline to implement the case at all, although I think
> that is silly. There is clearly at least *some* baggage here that we
> can remove.
>
> My personal preference is to just remove it all, probably in two
> phases. Phase 1 will implement the stuff specified here, as specified
> and approved. Phase 2 would be a new case to remove the "posttek",
> "postplot", "postdaisy" utilities, subject to separate PSARC and
> C-Team/P-Team review.
>
> Any strong opinions here?
>
> - Garrett
>
>
> Garrett D'Amore wrote:
>> Sebastien Roy wrote:
>>> On Wed, 2009-10-07 at 22:56 -0700, Garrett D'Amore - sun microsystems
>>> wrote:
>>>
>>>> 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.
>>>>
>>>
>>> I don't see a release binding associated with this case. I give this
>>> case a +1 assuming that the binding is not less than Minor (i.e., this
>>> is not applicable for Patch or Micro).
>>>
>>> -Seb
>>>
>>>
>>>
>> Yes, it should have been minor. Thanks. This case was approved at
>> PSARC today, and has minor binding.
>>
>> - Garrett
>
