Re: Build fix for lang/python312 on macOS

[Greg Troxel <gdt%lexort.com@localhost>]

Pierre Pronchery <khorben%defora.org@localhost> writes:

>> In python 3.12.4, Modules/pyexpat.c, I see:
>> 
>>  static PyObject *
>>  pyexpat_xmlparser_SetReparseDeferralEnabled_impl(xmlparseobject *self,
>>                                                   int enabled)
>>  /*[clinic end generated code: output=5ec539e3b63c8c49 input=021eb9e0bafc32c5]*/
>>  {
>>  #if XML_COMBINED_VERSION >= 20600
>>      XML_SetReparseDeferralEnabled(self->itself, enabled ? XML_TRUE : XML_FALSE);
>>      self->reparse_deferral_enabled = (bool)enabled;
>>  #endif
>>      Py_RETURN_NONE;
>>  }
>> 
>> and I therefore suspect pkgsrc head will be ok for you.
>
> Unfortunately it does not help; 2024Q3 has 3.12.6 already anyway.

Interesting, because it builds on ok on macOS one version back for me,
which also has 2.5.0.   I wonder if apple did something else odd.

At this point I have to suggest debugging how it is going wrong.

>> There is a remaining question about whether we should add an API depends
>> to force pkgsrc expat, but that would need a solid argument that it's
>> worth it.  (And leading up to branch, concurrence from jperkin that it's
>> a good functionality/risk tradeoff.)
>
> One thing that might make it worth it, is security: almost every release of expat
> in the 2.6.x branch has been accompanied by security fixes. pkgsrc cannot fix each
> and every vulnerability present in the base system, but relying on the base can
> also expose the users to a false sense of security. (e.g., when looking at the
> version included in pkgsrc as opposed to that of the base system)

Doctrinally, we don't do that.  If you want something updated for
security, you should follow the security update practice for that
package.  Basically, we depend on things when there is a funtional
reason (api usage), and not because we want to tell people to do
updates.

What I meant is that python has an #if to avoid this API, if expat is
too old and it's not present.   The question is then: so what?  Is
python built to avoid this API deficient in any meaningful way?   Python
itself seems not to think so, or it would just say expat >= 2.6.0 as a a
requirement.

In other words, I meant is the loss of the API worth requiring newer
expat.

That's separate from you finding a new bug.

> In addition, this would help ensure a most consistent environment for pkgsrc
> builds across the different platforms supported - as illustrated by the issue I am
> having now on macOS.

That is basically saying people might want to PREFER_PKGSRC.  But pkgsrc
doesn't make that choice for people.

> OTOH, on native NetBSD, it means an extra copy of expat lying around, since it
> seems to be part of the base system. (For gdb, gettext, libarchive, unbound, and
> Xorg apparently)

That is why pkgsrc has a "use base if it is adequate" approach.


So far, we don't understand what is wrong.  In general I am
uncomfortable with changes not based on understanding.  Right now it's
not me that needs to be comfortable, but I think it's the same issue.