Cyril Plisko wrote: > 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 ? That isn't what this case is about though. This case is about optisations for the bzip2 binary to make it multi threaded (parallel). That shouldn't be exposed as a new program since it isn't a change of algorithm. 1991/061 doesn't say that what oyu are suggesting above but personally yes I think there should have been one compress/uncompress command that dealt with all the different algorithms - like we have /usr/bin/encrypt or what openssl(1) does. What 199/061 is is saying is don't do exactly what this case is doing which is fork when you don't have to. -- Darren J Moffat
