"Greg A. Woods" <woods%planix.ca@localhost> writes: > Many hiccups are simple enough to deal with, e.g. long gone packages > (especially when I don't care to have them any more) (though they're > terribly annoying to have to deal with given pkg_rolling-replace's > rather slow pace at figuring out what it wants to do next, and without > any way to easily report in one group all the things it will run into > trouble over) The -k flag more or less works for this. > However things that effectively get renamed when upgrading are not dealt > with at all gracefully by pkg_rolling-replace: There's renamed, and there's pyN->pyM. pkg_chk doesn't deal well with the latter and pkg_rr inherits that behavior. > RR> Selecting py27-setuptools (devel/py-setuptools) as next package to replace > RR> Checking if py27-setuptools has new depends... > /usr/bin/awk: unknown option -expat-[0-9]*:../../textproc/py-expat ignored > > /usr/bin/awk: unknown option -expat-[0-9]*:../../textproc/py-expat ignored That I've never seen. > So, I was wondering what people normally do in cases like this. > > I could just blow away all the packages needing this and then start > fresh with the current PYPKGPREFIX, but again pkg_rolling-replace isn't > very good at dealing with packages that have to upgrade/replace > dependencies it hasn't already accounted for. I have DEPENDS_TARGET= bin-install clean and removing things and rerunning mostly works, as long as when you delete a package you mark things that depend on it with "pkg_admin set rebuild=YES", or unsafe_depends. Really the pkg tools should set unsafe_depends on depending packages when pkg_delete -f is used. Also with -k, often the top-level package gets replaced which rebuilds lots of (this week) py39-foo, leaving a bunch of py38-foo or py27-foo that are no longer needed. So I frequently do 'pkgin ar' to drop things I don't need, and not trip over rebuilding them or conflicts with py27-foo and py39-foo. > Also, what should I expect to have to do when using the new binary > packages with "pkgin". I don't expect "pkgin fug" to work very well on > its own either, though perhaps it will do better than I expect. It works pretty well. You may have to pkgin export, remove things, and then pkgin add what you want. I generate a summary file. It helps to keep a clean list of "keep" vs not. (keep is true if automatic=yes is not true.) And it helps to 'pkgin ar'. I've been building on one machine (that I don't care if it is up any particular day) and doing pkgin fug on two servers that I do care about. It's been really close to totally ok on the servers, and minor hiccups on the build machine. If you don't like this, instead generate a needed list and configure a small bulk build.
Attachment:
signature.asc
Description: PGP signature