"Greg A. Woods" <woods%planix.ca@localhost> writes: >> I have >> >> DEPENDS_TARGET= bin-install clean >> >> and removing things and rerunning mostly works, > > I'm a little leary of bin-install -- and I'm OK with rebuilding things > extra times.... Sure, your call. For me it made me more willing to type "pkgin ar" frequently. Right now py27-scons and py39-scons conflict because they both install "scons", and there isn't USE_TOOLS+=scons to link py27-scons into .buildlink/tools/bin/scon, so if you have something that uses py27-scons you need to keep removing it. And there are other build tools. In theory with revbumps it's ok. Usually it is, not always. > In the end I just did this: > > # pkg_delete -r python27 python37 That's ok as long as you won't want e.g. py39-paho-mqtt as a non-automatic package, and it's ok anyway if you make a list which you did. > Doing the first three (the p5-* ones) also did not remove their entries > from the perl-5.xx/+REQUIRED_BY file, though I don't quite understand > why not. Are you sure, or could it be that there were two entries, and 1 got removed leaving 1? > There were a huge number of other p5-* packages too that didn't get > replaced by the version rebuilt by pkg_rolling-replace, but rather the > updated version was simply added, so I ended up with a large number of > "duplicate" entries (i.e. two different versions) in the > perl-5.xx/+REQUIRED_BY file and had to manually remove them. Or it was messed up before. I have seen this, and happening on p5- rings a bell. It happens from time to time that there are two entries for a package in +REQUIRED_BY, and once it happens it persists until cleaned up. I run "pkg_admin rebuild-tree" which scrubs all of these; that's one step of what "pkg_admin fsck" ought to do. > For these cases of duplicate +REQUIRED_BY entries I think maybe that > pkg_rolling-replace re-built the dependency (e.g. gtar-base) before > rebuilding the package that required it (e.g. gtar), and I think the pkg_rr basically always does that, or at least that's the design. > logic to fiddle with the +REQUIRED_BY file in > pkgsrc/mk/pkgformat/pkg/replace.mk is possibly suspect, though I don't > quite understand it all yet. It works correctly almost all the time. I dimly remember that there was a bug in an odd case and 60% remember that it was fixed. If you can find a bug clearly please let me know. > (though for my systems the setting for automatic=yes is only reliable on > systems that only have binary installs using pkgin) I keep it accurate by running 'pkgin sk' and then 'pkgin uk' or 'pkgin keep', even on systems where I only build from source (plus bin-install of packages I have built). make package-install results in automatic unset, dependency install results in automatic=yes, and make replace doesn't change automatic. Part of why I keep automatic correct is that I run 'pkgin export' on all my systems of a given version/arch (e.g. netbsd-9 amd64) and union them, and then set difference from the union to the build machine and then I build those. That means my own binary package set is usable on all of the machines. (The build machine is just for building; it's a 2008 macbookpro, someday to be a xen domU.)
Attachment:
signature.asc
Description: PGP signature