Hello again,
On Sat, 12 Nov 2016 15:38:24 +0100 Guillem Jover <[email protected]> wrote: > There are some problems with the proposed patch: it incurs a > performance degradation on any other module loading Dpkg::Compression > regardless of those ending up using gzip, Does that mean you're loading Dpkg::Compression unconditionally? And, after you fix *that* problem, Dpkg:Compression might still not use gzip at all? Then why don't you move the entire check to right before it's actually going to be used? > when users are already > complaining the perl module loading is already too slow; I'm in > general not a very big fan of conditionalizing on --help output; and > just requiring the option now unconditionally and expecting a recent > enough GNU gzip would not be very enticing, as at least various > (most) of the BSD gzip implementations do not have --rsyncable > support. You would always catch incompatible implementations either because --help is not a supported option or because --rsyncable is not a supported option, and then you would not try to use --rsyncable. ( I could give you execution times for gzip's help output. perl's system() overhead should be negligible too. ) > I could perhaps try to detect this at configure time (which seems > mildly wrong too), or just add Gentoo to the whiltelist if you can > tell me the value of $Config{cf_by} there? That would be even worse. If you later updated gzip to a version that supports --rsyncable, or patched gzip to support --rsyncable, you would need to re-install dpkg? And that whitelist would not work either. For lots of reasons. I could give examples. > But then I'm not sure it's > very important to have rsyncable enabled on systems were dpkg is not > the native package manager? Having dpkg on systems where dpkg is not the package manager is useful when you want to deploy a dpkg based system, say through debootstrap. > I also noticed few other things in the Gentoo ebuild, that you might > want to fix: Thanks. I'll pick those up with the next bump. Regards, jer
