[illumos-Developer] review: nuke staleness from svr4pkg

[Roland Mainz]

On Tue, Oct 19, 2010 at 7:54 AM, Garrett D'Amore <garrett at nexenta.com> wrote:
> On Tue, 2010-10-19 at 07:45 +0200, Roland Mainz wrote:
>> On Tue, Oct 19, 2010 at 7:18 AM, Alan Coopersmith
>> <alan.coopersmith at oracle.com> wrote:
>> >> I think this is covered already.   "patchadd" and its ilk are closed
>> >> source, and basically are utter garbage anyway.
>> >
>> > Actually, source was available for patchadd & patchrm (they are shell
>> > scripts after all), and they were included in first release of the
>> > OpenSolaris distro, before they were removed for being incompatible
>> > with ksh93:
>> >        https://defect.opensolaris.org/bz/show_bug.cgi?id=1944
>>
>> Erm... AFAIK this was less a problem with ksh93 and more an issue that
>> Sun "enhanced" Solaris ksh88 and switched "typeset -i" from a 32bit
>> integer declaration to to a 64bit integer declaration (which was wrong
>> (and badly implemented), broke some scripts, broke interoperability
>> and _now_ again causes trouble because Sun's script now rely on this
>> Solaris-specific feature). Sun once had the OpenGroup patch to add
>> "typeset -l -i" to ksh88 (basically a backport from early ksh93
>> versions) but instead opted to increase the datatype width for
>> "typeset -i" instead (because it was easier/faster to implement (see
>> [1] below, the management thought it is easier to do this instead of
>> replacing s/typeset -i/integer/g in the SystemV package scripts).
>>
>> [1]=The korn shell (written for ksh88, but it applies to current and
>> all planned versions of ksh93, too) documentation (e.g.
>> http://www.amazon.com/New-KornShell-Command-Programming-Language/dp/0131827006)
>> explicitly says that the alias "integer" always refers to the largest
>> integer datatype available to the interpreter, e.g. 32bit for ksh88
>> and 64bit for current ([2]) ksh93 versions (fortunately even Solaris
>> ksh88).
>> [2]=Once |int128_t| becomes more common we'll see 128bit integers in
>> ksh93, too (but implemented via a new typeset option to avoid that we
>> break scripts which explicitly requested a specific datatype (but the
>> "integer" alias will then refer to the larger datatype (see [1]))).
>
> There were many reasons that patchadd and patchrm had to go.

What exactly were the other reasons (except this issue and that the
patch generation scripts were closed) ?

> Shell
> compatibility was probably the least of these.

Well, I'm happy to do the s/typeset -i/integer/ replacement job if
anyone wants such scripts back...
... and in general we should do a tree-wide sweep and catch all
instances of "typeset -i" and replace them with "typeset -li" ...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)