>On Thu, Jun 06, 2013 at 14:20, Mark Kettenis wrote: >> I've ranted before about implementing "standard" tools in Perl. The >> user experience just isn't the same as with C code. >> >> But even more so than with nl(1), why would we want to use something >> that's different from what everybody else uses? If we want bzip2 in >> base (and I think there are good reasons for having it) we should >> simply use the standard bzip2 code. > >I don't have a problem with importing bzip2, per se. But iirc previous >discussions basically ended with "it adds more code and will slow down >builds."
If I recall, previous discussions were not about "but then we can use it as a complete replacement for gzip or use it for the install media or ...", as if this is a general replacement algorithm. >But we've already been slowing down builds for the past two >years. Adding another copy of the C version returns us to the bloat >discussion. I'm trying to dance around that objection by using code >that already has been imported and built. If it is now very common, we might as well put it in base properly. >It's not so much that I really need bzip2 in base. But having paid the >cost to build, I'd like some return on that investment. At least >that's my rationale. If the code built in base will just be picked up by perl, fine. It is primarily used by ports. If anyone thinks using this for the install or boot media is going to help, don't say a word until you can prove it on all platforms.
