Bug#760473: Further analysis and a patch
August 11 2015 7:54 PM, "David Kalnischkies" <david@kalnischkies.de> wrote:
> apt does not link indirectly to libnettle nor to libcurl-gnutls. The
> optinal apt-transport-https does. That is a big difference for
> bootstrappers as it means they can ignore -https for the time being
> until the base system is up and running and can then be used to build
> "proper" packages.
I was indeed wrong about that assumption. wget on the other hand, which is
marked important and part of the base system, is linked against libnettle.
So the library will most likely exist on all but the most minimal systems
on which the base system is not defined by the debian policy.
> So, big thanks for the patch, but I have to pull the marker as we can't
> apply it as is. What could be done maybe is dlopen libnettle (and/or
> others if available) and use them and otherwise fallback to our own
> slower but always available code. We could then Recommends libnettle and
> make everyone happy, I guess… just, libnettle seems to be a bit too
> unstable in its ABI, which is another problem with this patch ATM as
> every ABI break in nettle means we are required to make one in
> libapt-pkg, too, entangling use in their transition…
> Caused by e.g. SHA256Summation having a struct sha256_ctx member, which
> could have a size change in a newer libnettle abi, so the size of
> SHA256Summation would change, too (that could be avoided through via the
> use of a d-pointer).
I get your point but the wget authors did consider it to be stable enough to
include it in their software. I might have a look at rewriting the patch
as a dynamically linked version. In which case I could also add openssl,
which is also part of the base system, as second fall-back.
>
>> In the process of finding the culprit I also replaced the http method
>> with a new version using libcurl. Similiar to the https method. This
>> change does not provide any measurable speed boost as of yet, as the
>> whole process is still waiting for the hashing to complete. I attached
>> the patch nonetheless as it removes a lot of redudant code.
>
> Same problem. http is in apt directly as 99% of all mirrors are
> http-only, so it is how you usually operate apt, -https is used by…
> very few people/mirrors.
>
I'll probably won't have a second look at this patch as it brings almost no
benefit to the table at the current point in time. It just made the HTTP
implementation a lot more stable.
Regards,
Lennart
Reply to: