-=| Felix Lechner, 16.03.2020 11:34:51 -0700 |=- > On Mon, Mar 16, 2020 at 10:29 AM Damyan Ivanov <d...@debian.org> > wrote: > > > > Any idea how many packages are we talking about? > > Below is my working list for filing bugs. It is based on a full text > search from codesearch.d.n. > …
I count 30 packages that need fixing (with filed bugs or not examined or marked with "htto"). These would be the packages to patch if we do the "fix the client" way. I was also interested in the count of failing packages when the root (e.g. libhttp-tiny-perl/src:perl) is fixed instead. Fixing the root of the problem seems better for me for two reasons: 1) fix what is broken instead of working around it in numerous places 2) consumers outside of Debian would benefit too 2) is true even if the root fix is not applied upstream, since I imagine many consumers of 3rd party Perl stuff still use Debian packages as a base. Note that planting work-arounds in these 30 packages with Debian specific patches is not good enough in my book, and taking 30 patches upstream is not a trivial thing. Imagine having the conversation that was had with HTTP::Tiny's author with 30 other authors who have different opinions on what is the right thing to do. I'd rather have two packages with Debian-specific patch. But to fully measure the impact, it would be nice to have the number of failing packages built with a patched HTTP::Tiny. I guess my contribution to this would be trying to find that number out. (And certainly not patching 30 packages unless other approaches are determined inappropriate). I can't say how long that would take, so please anybody, feel free to beat me to it. If we can prove that patching HTTP::Tiny plus several failing test in other modules is achievable, we may have a chance convincing HTTP::Tiny's author to flip the default (esp. if the patches for the failing tests are applied upstream) -- it is 5 years later after all, and https is everywhere. -- Damyan