[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: PATCH: dpkg: Check for gzip --rsyncable

     Hello again,

On Sat, 12 Nov 2016 15:38:24 +0100
Guillem Jover <guillem@debian.org> 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.


Reply to: