I tend toward keeping things simple, and demanding the minimum from the
user, so requiring the user to provide the location of the pkgsrc tree
every time is something I would avoid unless it's really necessary.
Though, I have thought about making it an option for more advanced users
if that would be helpful to anyone. I suspect, though, that such users
don't need a tool like auto-update-pkgsrc. It's aimed more at helping
the typical user expedite the process and avoid human error.
The current implementation in wip makes no assumptions about the
location of the tree relative to PREFIX. It's taken from PKGSRCDIR,
which appears to be recorded during bootstrap. Assuming that moving a
pkgsrc tree after bootstrapping is considered a bad idea for other
reasons, this should not be a limiting factor.
Right, but you can guess the LOCALBASE from the pkgsrc tree, assuming that the environment is correctly set up.
Or you could (ab)use pkg_info to tell you where it expects things set up (again, assuming the environment is set up correctly)
# discover localbase
case "${localbase}"in
"") localbase=$(cd ${pkgsrc}/pkgtools/digest && ${make} show-var VARNAME=LOCALBASE)
;;
esac
case "${localbase}"in
"") localbase="$(${pkg_info} -Q LOCALBASE digest)"
;;
esac
I'm not sure what you meant by "updated the whole tree to the latest
branch". Can you elaborate?
It seems that the pkgsrc tree I had been using suddenly gained all these pesky Tag files in their CVS directories, meaning that the tree was now on the release branch, rather than (an admittedly older) current.
Easily recoverable by using cvs -dPA (or even easier by just removing the Tag files en masse, and then updating via cvs)
Again, thanks for auto-admin, and being so responsive to feedback
Best wishes,
Al