Re: git: b883eac8e32d - main - devel/meson: enable FLAVORs

Am 12.03.23 um 03:04 schrieb Charlie Li:
> Jan Beich wrote:
>> Charlie Li <vishwin@FreeBSD.org> writes:
>>
>>> -BUILD_DEPENDS=    meson>=0.63.3:devel/meson \
>>> +BUILD_DEPENDS=    meson:devel/meson@${PY_FLAVOR} \
>>
>> Looks non-deterministic as "meson" maybe provided by default flavor
>> instead of the requested (via FLAVOR + USES=python -> PY_FLAVOR) e.g.,
>>
> Continuing to use the version specifier wasn't exactly tenable due to 
> the conditional PKGNAME change. Unfortunately this also means those not 
> using isolated build environments get the short end of the stick for 
> now, until USE_PYTHON=concurrent is tackled (so that the versioned entry 
> point can be used instead).
>>    $ pkg install meson
>>    $ make clean all FLAVOR=py310 BUILD_ALL_PYTHON_FLAVORS=y -C 
>> devel/meson-python
>>    [...]
>>    ===>  Building for py310-meson-python-0.12.1
>>    * Getting build dependencies for wheel...
>>
>>    ERROR Missing dependencies:
>>            meson>=0.63.3
>>    *** Error code 1
>>
>>> +.if ${PYTHON_VER} != ${PYTHON_DEFAULT}
>>> +PKGNAMESUFFIX=    ${PYTHON_PKGNAMESUFFIX}
>>> +.endif
>>
>> Avoiding USE_PYTHON=concurrent without hiding non-module files?
>>
>>    $ pkg install meson
>>    $ pkg install meson-py311
>>    [...]
>>    Checking integrity... done (1 conflicting)
>>      - meson-py311-1.0.1 conflicts with meson-1.0.1 on 
>> /usr/local/bin/meson
>>    Checking integrity... done (0 conflicting)
>>    The following 4 package(s) will be affected (of 0 checked):
>>
>>    Installed packages to be REMOVED:
>>            meson: 1.0.1
>>    [...]
> The man pages are part of the sdist and catalogued as data_files in the 
> bdist, so despite them getting installed in the appropriate directory, 
> are part of the module. USE_PYTHON=concurrent should take care of these 
> but need to double check.
> 

Charlie,

PLEASE stop rushing in commits of half-baked junk,
and either fix this within a week, or even better, back it out today, 
until this is complete.

It would also be better to get the things you'd started earlier fixed 
and in, before starting on new things (I am thinking of the __pycache__ 
and bytecode trigger from <https://reviews.freebsd.org/D34739>). Else we 
have a non-fitting collection of half-baked Python brokenness.

https://reviews.freebsd.org/D39004 also documents that you experiment in 
the live public ports tree and rush things out long before they're even 
review worthy.  It also was not reviewed.  The __pycache__ cleanup  Your 
current approach to ports@ quality is not sustainable.

Regards
Matthias