Richard PALO <richard%netbsd.org@localhost> writes: >> RR> pkg_install has the following new depends (need to re-tsort): >> rr> [pkg_install-info perl readline zlib] >> RR> Tsorting dependency graph >> RR> Selecting pkg_install (pkgtools/pkg_install >> pkgtools/pkg_install) as next package to replace >> Usage: dirname [ path ] >> *** No package directory 'pkgtools/pkg_install >> pkgtools/pkg_install' for pkg_install. >> *** Please read the errors listed above, fix the problem, >> *** then re-run pkg_rolling-replace to continue. It's hard to tell where the bug is, but generally the two things to do to resolve this sort of thing are: outright remove pkg_install (on systems where there is base pkg_install) in pkgtools/pkg_install, do make replace Note that all pkg_rr does is decide what order to do make replace. So you have to separate picking the wrong order from problems with the operation itself. In this case, it seems that PKGPATH is two words: > *** No package directory 'pkgtools/pkg_install > pkgtools/pkg_install' for pkg_install. which could be a bug in the installed package or a pkg_rr bug. You could do pkg_info -B and see what the value in the package is. For me: $ pkg_info -B pkg_install|egrep PKGPATH PKGPATH=pkgtools/pkg_install which seems right. If yours has PKGPATH=pkgtools/pkg_install pktools/pkg_install then I would just hand-edit the +CONTENTS, or do make replace.
Attachment:
signature.asc
Description: PGP signature