pkgsrc-Users archive

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

Re: enable icu support by default in libxml2



Peter Lai <cowbert%gmail.com@localhost> writes:

> On Thu, Mar 18, 2021 at 8:42 AM Greg Troxel <gdt%lexort.com@localhost> wrote:
>
>>
>> Thomas Klausner <wiz%NetBSD.org@localhost> writes:
>>
>> > (If we don't do that, qt5-qtwebengine will need to build against its
>> > included libxml2, and we'll have to patch libxml2 problems/security
>> > issues in that code base as well.)
>>
>> Two separate thoughts:
>>
>>   We're going ito freeze in few days, so it doesn't seem like a good
>>   time to make a big change to something that has a huge reverse
>>   dependency footprint.  But maybe icu support is normal (in that most
>>   other packaging systems have it enabled), and maybe icu really does
>>   build everywhere libxml2 does.  If qt5-qtwebengine isn't going to be
>>   imported before freeze, I don't see any reason to do this now vs just
>>   after freeze.
>>
>>   77 MB to process unicode, vs only 10 MB for libxml2.  Not actually a
>>   big deal, but wow!
>
> Also, it seems like if it bundles its own libxml2 that should be qt5
> upstream's problem to support, no?

No, not really.  pkgsrc has a notion that we (in a vague, no warranty,
no one is responsible sort of way) try to resolve security issues.  So
if there's a report against libxml2, and a patch, then even without the
point release that ought to happen, typically someone would add a patch.

If libxml2 is i qt5's repo, then you are suggesting that they are
somehow responsible.  To be truly responsible, they'd need to have a
point patch release of every current release they have that includes
libxml2 within say 48h of a libxml2 patch being available.

And, to make this easier, on top of that. qt5 would have to update
libxml2 in everything that contains it, soon (30 days?) after every
libxml2 release, and then issue a new point release of the qt5 project.

Either of those are just not credible expectations in practice.  I don't
know of any upstream that meets them.

So, to fix this, someone in pkgsrc would have to apply the patch for the
qt5 package.  Hence, we don't want to be in this position; it's basicaly
a wrong thing to do to carry a copy of another package in a packge's
source, justified only by having to build in broken environments.

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index