replication of stuff in /usr/gnu

[Stephen Hahn]

* Garrett D'Amore <garrett at damore.org> [2007-07-03 15:12]:
> I happened to notice that we ship two different versions of a few very 
> trivial programs:
> 
> -r-xr-xr-x   1 root     bin         7860 Jun 17 14:37 /usr/bin/yes
> -r-xr-xr-x   1 root     bin        19616 Jun 14 13:06 /usr/gnu/bin/yes
> 
> 
> -r-xr-xr-x   1 root     bin         7708 Jun 17 14:21 /usr/bin/true
> -r-xr-xr-x   1 root     bin        15100 Jun 14 13:06 /usr/gnu/bin/true
> 
> -r-xr-xr-x   1 root     bin         7888 Jun 17 14:36 /usr/bin/logname
> -r-xr-xr-x   1 root     bin        19748 Jun 14 13:06 /usr/gnu/bin/logname
> 
> -r-xr-xr-x   1 root     bin         8084 Jun 17 14:21 /usr/bin/pwd
> -r-xr-xr-x   1 root     bin        24176 Jun 14 13:06 /usr/gnu/bin/pwd
> 
> -r-xr-xr-x   1 root     bin         7948 Jun 17 14:20 /usr/bin/hostid
> -r-xr-xr-x   1 root     bin        19692 Jun 14 13:06 /usr/gnu/bin/hostid
> 
> The GNU versions only differ in that they accept a pointless --help and 
> --version option.
> 
> and a few that where the GNU differences are so trivial that it hardly 
> seems worth shipping a separate binary:
> 
> nohup:  The Sun version is a superset of the GNU version
> 
> -r-xr-xr-x  72 root     bin         8100 Jun 17 14:21 /usr/bin/nohup
> -r-xr-xr-x   1 root     bin        23032 Jun 14 13:06 /usr/gnu/bin/nohup
> 
> cksum:  The only difference is the type of whitespace separating the 
> checksums (tabs vs. spaces)
> 
> 
> It strikes me as a really unfortunate thing to deliver two versions of 
> the same programs, when there is no differentiating functionality, or 
> even command line options.
> 
> Is there anything we can do to clean this up, and to avoid it in the future?

  (Although you find --help and --version pointless, many *ix users now
  expect commands to process these options.)

  The current choice to ship GNU command variants was made to economize
  utility developer time, in that it's a questionable use of time to
  enhance our commands to be supersets of their Solaris-historic,
  XPG4/XPG6, and GNU behaviours, rather than to ship the upstream
  versions in a separate location.  During the discussion that led up to
  2007/048, it was noted that deviations from the standard GNU coreutils
  installation pattern would also lead to dissatisfied populations; as a
  result, we elected to minimize the differences in our installation (to
  omitting the su(1M) variant and following the "alternative
  environment" pattern for /usr/xpg[46]/bin).  People assembling
  distributions have the SUNWgnu-coreutils package boundary to base
  their decision on, or can repackage the SFW proto area to their
  liking.

  I suppose my question is "what engineering quality are you trying to
  optimize?", since your example involves 12 pathnames and ~200k of disk
  space.  In any case, sfwnv-discuss is the correct place to have the
  conversation, since we're continuing to integrate OSS tools and
  utilities of this kind.

  - Stephen

-- 
sch at sun.com  http://blogs.sun.com/sch/