On Tue, Apr 28, 2009 at 6:30 PM, James Carlson <james.d.carlson at sun.com>
wrote:
> If it just installs alongside the existing bzip2, isn't this project
> in conflict with PSARC 1991/061? ?In particular, we said this:
>
> ?The rule we agreed to is:
>
> ? ? ? ? ?Each component of the system can appear in only one package.
> [...]
> ?A component is not really (only) a binary piece of the system. ?We
> ?don't want two products taking the same source code, with their own
> ?slightly different hacks, and shipping it. ?We also don't want two
> ?products taking completely different source code and shipping it under
> ?the same name.
>
> This project seems to run afoul of at least that first part.
I do not want to generalize, but with compressor/decompressor it is a
very common to have many different algorithms to be supported within a
single executable. The most widely known example is gzip, which
happens to being able to handle .Z files as well as .gz. Following the
above guidelines there should be no place for both compress and gzip,
as they implement same algorithm/code (among other things). There are
more examples - 7z(1) can handle 7z (that implements LZMA compression
algorithm), ZIP, CAB, ARJ, GZIP, BZIP2, TAR, CPIO, RPM and DEB
formats. Does that mean we should have ditched unzip, gzip, bzip2, tar
and cpio binaries when 7z have been integrated ? I don't think so.
Can it be that the reality changed since 1991 and PSARC 1991/061
should updated for the 21st century ?
--
Regards,
Cyril
