Hej, > Am 01.08.2023 um 14:49 schrieb Greg Troxel <gdt%lexort.com@localhost>: > > oskar%fessel.org@localhost writes: > >>> There have been no comments objecting to moving the default to 3.11 >>> after 3.5 weeks and one positive comment. >> I was fine with that expecting nothing serious. > >> But on the production machine i run i was updating perl to 5.8 and >> that hit me in the middle because some of the dependent packages >> (which seem to be essentially all ;-)) was dependent on some python >> stuff. The production ran 3.9 since forever but the new default >> triggered some package builds with 311. not a problem, i thought. > > The default has not actually been changed yet. See > lang/python/pyversion.mk. It is merely waiting for someone with the > cycles to deal with revbumping the packages that don't have a pyNN > prefix. As noted later by you, i wasn’t quite explicitly saying, that I changed the default on the machine in question. sorry for that > > Are you really running pkgsrc-current in production? I would advise > against that, especially without a staging build machine. I have a staging setup „on the production machine“ - which i strongly advise to not do at home... > >> Until make update bailed out: > > pkg_chk and hence pkg_rr don't deal well with multiversion packages that > aren't the default. I usually find the set of packages that I want > installed, pkgin uk those and pkgin ar, and then build anew. Of course > that's on a non-production machine where it doens't matter if it is > temporarily missing things. that’s reasonable ;-) > >> => Tool dependency py311-packaging-[0-9]*: NOT found > > You didn't say what needed that and why. Sorry, that was because of perl update to 5.8 was not handled by pkg_rr on that machine without stopping at every package „another version is installed“… The package that explicitly had py311-<somthing> as a tool dependency was a2ps, which as rebuilt because of perl. >> The following variables will affect the build process of this package, >> py311-packaging-23.1. Their current value is shown below: >> >> * PYTHON_VERSION_DEFAULT = 311 > > Did you change that yourself? Unfortunately yes, didn’t bite me for over two months... > >> This is quite reasonable, in that pyhon311 is not installed. But shouldn’t it be installed if something needs it, like a python311-package? > > Yes, and generally this works. in this case obviously not. > >> And yes, this can be fixed manually. And yes, I am to blame because i >> did not fix pyhton39 as the default for this machine… > > I don't follow "did not fix python39 as the default". I forgot the mantra „Do not build with flexible settings for production“. I should not have changed PYTHON_VERSION_DEFAULT... > > I suspect you have odd content in mk.conf, and/or a broken dependency > database. Overall I recommend (and you are of course welcome to take > each piece advice or not!): > > - deal with production machines by using a quarterly branch I cannot do that while exposed to the internet. As soon as a relevant security issue comes up, i feel compelled to fix it. When pkgsrc-current already has a fix, that works for me. > - deal with production machines by creating binary package sets check. > - examine/prune mk.conf check. > - pkg_admin rebuild check. > - pkg_admin rebuild-tree check. > - pkg_admin check i don’t know if that does something more useful than what i already have in place with beefed up tripwire. > - install pkgin, look at "pkgin sk|sort", "pkgin uk" things you don't > intend to have installed, examine "pkgin -n ar|sort", and if you > are ok with uninstalling those, "pkgin ar". When doing upgrades the > less you have the better and I find software accumulates if I don't > purge. i use pkgin on my other machines but switched back to pkg_* for this one. Don’t know why, it just feels more controllable - but as you can see, this may not be really true. Basically, this was just to point out that probably something is not DTRT. Unfortunately, all other machines i currently have running uses python311 only, so no good way to replicate that on a cleaner system. Cheers Oskar
Attachment:
smime.p7s
Description: S/MIME cryptographic signature