D'Arcy Cain <darcy%NetBSD.org@localhost> writes: > I am mostly using the latest Python (just converting to 3.6 now) but I > still have a few modules that need to be built for 2.7. Somehow > pkg_chk is listing some of those as 3.6 and thus showing as missing. > This seems to be those packages that have only a 2.7 version built. > For example, let's say I have these packages installed: > > py27-authres-0.800 > py27-babel-2.3.4 > py36-babel-2.3.4 > py36-crypto-2.6.1nb2 > > According to pkg_chk I have the following installed: > > py36-authres-0.800 > py36-babel-2.3.4 > py36-crypto-2.6.1nb2 I have also run into this, and mostly I've just ignored it because I have just upgraded from 2.6 to 2.7. I think the fix is to change the way pkg_chk deals with multiversion packages and have it report each version separately, and not consider python27-foo out of date because the default is 36, etc. This does mean pkg_chk will then not help move from one version to another. But arguably that's ok, since they exist as separate packages. > I tried looking through the script but I am not sure that there is a > good fix for this. As I see it two things need to be fixed, list the > actual packages on the system and allow make to build arbitrary > versions instead of looking at mk.conf. I tried to do the latter with > "make -DPYTHON_VERSION_DEFAULT=27 install" but it still tried to build > 3.6 as defined in mk.conf. Do you have ?= in mk.conf? I am wondering if this is just make variable precedence.
Attachment:
signature.asc
Description: PGP signature