Re: pkg(8): difference between "-c /path" and "-r /path"

Guys,

see inline

On Mon, Feb 27, 2023 at 8:58 AM Baptiste Daroussin <bapt@freebsd.org> wrote:
>
> On Sun, Feb 26, 2023 at 10:07:14AM +0100, Michael Schuster wrote:
> > Hi,
> >
> > This question is (as of yet) more of the "fill in background info" type:
> > From the "pkg(8)" man-page:
> >
> >      -c <chroot path>, --chroot <chroot path>
> >     pkg will chroot in the <chroot path> environment.
> >
> >      -r <root directory>, --rootdir <root directory>
> >     pkg will install all packages within the specified <root
> >     directory>.
> >
> > up to now, I've leaned towards "pkg -c /path <cmd>" when
> > installing/updating a BE mounted at /path, but, given some results in the
> > past that weren't quite clear to me (yes, that's a bit vague, sorry), I've
> > been wondering whether "-r /path" would have been better.
> >
> > I'd appreciate thoughts/advice/comments, TIA
> > Michael
>
> pkg -c will chroot (real chroot as in chroot(2)) into the directory at early
> stage and execute everything from the inside.
>
> This means that for post install script the kernel of the host needs to be able
> to run the binary withing the guest (for instance you cannot cross install).
>
> For the packages themselves it is transparent if that is the case.
>
> pkg -r, will run everything from the host and with the provided rootdir prepend
> to all path in the packages and database, post install scripts needs to know
> about PKG_ROOTDIR variable (which is not the case for many of them in the ports
> tree). triggers will be deffered (to be run at next boot).
>
> pkg -r allows cross installation (preparing an arm64 rootdir on a amd64 host).
>
> In long term pkg -r is preferred, right now pkg -c is probably most of the time
> safest.

my main use case is keeping the current installation (13 Release for
now) up to date and to have a fallback when installing new software;
in that case, if I understand your comments correctly so far, either
should work equally well.

thx
Michael
>
> Best regards,
> Bapt



-- 
Michael Schuster
http://recursiveramblings.wordpress.com/
recursion, n: see 'recursion'