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 ?
>
>
I believe that this case represents a linux familiarity case. While I
am no happier about the delivery of a separate object with slightly
different command line switches and operational semantics than anyone
else on this list, I do believe that we've already long ago established
the precedent that except for "critical pieces" of the core
architecture, we are willing to abdicate "good architecture" in favor of
"familiarity", except in the case of particularly gross violations --
such as cases which would have a negative impact on system security or
on the usability of other components in the system.
So, since this particular piece of software more or less stands alone
and is already out in the FOSS arena, I don't think we need to hold it
up to the same level of architectural scrutiny that we would give
something that was a core piece of architecture.
It *might* be a good idea, though, if we could give it a stability level
that discouraged (or even prohibited) its use by other more "core"
portions of the architecture. (For example, I would consider it an
error for the packaging system to suddenly start making use of pbzip2
given the reduced level of review that this case has received, and the
fact that if accepted as specified there will be several significant
reservations about how it operates.)
-- Garrett
