> > ${BUILD_PACKAGES:M-tkinter} ?
>
> do you mean LIB_DEPENDS-tkinter, WANTLIB-tkinter, etc? if so, no, these
> should be set unconditionally
>
> I simplified this bit, no worries. Nicer, even.
oh, actually BUILD_PACKAGES:M-tkinter makes no sense here as there
is no no_tkinter PSEUDO_FLAVOR..
> any more info on that?
>
> # pkg_add python-3.10.4.p1 ; pkg_delete python-3.10.4.p1
> ...
> Error deleting directory /usr/local/lib/python3.10: Directory not empty
This is because there are files in PLIST-main in 3.10 with no parent
directory. However they are duplicate files as they are also in PLIST-tests
so should be removed from main. I'll fix that separately
> > @so lib/python2.7/lib-dynload/datetime.so
> > @so lib/python2.7/lib-dynload/dbm.so
> > +@so lib/python2.7/lib-dynload/dl.so
> > @so lib/python2.7/lib-dynload/fcntl.so
> > @so lib/python2.7/lib-dynload/future_builtins.so
> > @so lib/python2.7/lib-dynload/grp.so
> > +@so lib/python2.7/lib-dynload/imageop.so
> > @so lib/python2.7/lib-dynload/itertools.so
> > @so lib/python2.7/lib-dynload/math.so
> > @so lib/python2.7/lib-dynload/mmap.so
>
> you added those to PLIST-main, shouldn't they be in PLIST-tkinter?
>
> Not me, the port did - I swear!
> $ cd /usr/ports/lang/python/2.7; make fake; make update-plist
> Should yield the same result for porters who are not me.
> Those .so's aren't part of TkInter.
Yet the change to tkinter caused them to build. So if there _was_ a
no_tkinter PSEUDO_FLAVOR then packaging -main would fail if the
CONFIGURE_ARGS was not used. But then the question is why they're
now built.
However imageop is meant to be disabled on 64-bit anyway!
# Disabled on 64-bit platforms
if sys.maxsize != 9223372036854775807L:
# Operations on images
exts.append( Extension('imageop', ['imageop.c']) )
else:
missing.extend(['imageop'])
And dl is meant to be disabled unless sizeof(int) == sizeof(long) ==
sizeof(char*)
So the change for tkinter is causing something deeply strange with
platform detection, we really need to figure out what's going on with
that
