Peter Tribble writes: > On Tue, Apr 28, 2009 at 5:25 PM, Darren J Moffat <Darren.Moffat at sun.com> > wrote: > > Garrett D'Amore wrote: > >> > >> 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. > > > > That part can be addressed with a single source and hardlinks so that both > > pbzip2 and bzip2 appear in the filesystem. > > > > The point here is we don't want to waste resources maintaining two copies > > when they are so very close to each other. > > But they aren't close. We're talking about two independent and subtly > incompatible implementations with different behaviour.
That's not what the documentation says, nor does it appear to be the intent of the pbzip2 author, at least based on his web site. It's unclear to me whether the 1.0.2 limitation is (a) dependent on the merge required due to parallel operation [i.e., if limited to single-threaded, it goes away], (b) a necessary artifact of the new code, or (c) really important at all to anyone [isn't 1.0.2 already many years old; I think 1.0.1 dates from 2001]. > Simply delivering both directly from upstream not only best satisfies user > expectations but is also the lowest maintenance; maintaining our own > independent fork is being deliberately incompatible and expensive. I disagree. I think forking the utilities in the file system for trivial internal implementation changes (merely because the community forked) is at least as bad as what you're suggesting. Given that there've been security issues in these programs, I think it's important to avoid doing this. Assuming the project team can come up with a utility that preserves some required amount of output format compatibility *and* that allows parallel operation, do you care about or have a need to pass through two different implementations? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
