[Slackbuilds-users] Problems with libev source

[B Watson]

On 12/24/17, Daniel Prosser <dpross1100 at msn.com> wrote:
> Okay, fair enough. Just to be clear though, it makes sense to you that
> this problem does not occur for every tar archive downloaded with wget
> (or the browser), hosted at any site? I've only encountered the problem
> with files from the libev download page, so there seems to be something
> different about those files that causes wget and the browser to compress
> them when downloading, if that is indeed what's going on.

I can name 2 more SBo examples: audio/alsacap and games/gtklife. These two
are different from yours (the saved file is un-gzipped, not double-gzipped
like libev) but the cause and workaround are the same.

It's not the file itself, it's the server that's serving the file. It's
sending a 'Content-encoding: gzip' header, which is redundant (the actual
file is already gzipped). The old version of wget disregards this header,
and the new version acts on it by default.

It also sends a Content-type header, as usual... if the Content-type is
application/x-tar, wget and your browser "helpfully" decompress the file.
If it's application/x-gzip, wget and your browser (sometimes, not sure
what else is happening) will "helpfully" gzip the file, even though it's
already gzipped.

You could argue that this means the server is misconfigured, and you
might be right... but the fact remains, the old wget did one thing when
talking to these servers, and the new one defaults to doing a different
thing. Slackware 14.2 is supposed to be a stable release, meaning that
patches aren't supposed to cause major changes in behaviour (which is
exactly what we're seeing here). The wget devs acknowledge this is a
bug, too:

http://lists.gnu.org/archive/html/bug-wget/2017-11/msg00059.html

If it were just me, I'd switch to curl and forget about it. But tools like
sbopkg and sbotools use wget... also, so does slackpkg (some Slackware
mirror might cause this same problem).