NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: /usr/pkg and unprivileged pkgsrc in parallel



Jörn Clausen <joernc%googlemail.com@localhost> writes:

> Now I want to add an unprivileged installation, that I want to
> distribute via NFS (hence the question regarding symlinks the other
> day, as they appear when using amd). The source directory is
>
> /vol/pkgsrc/20190803/pkgsrc
>
> and I bootstrap with
>
> $ ./bootstrap --prefix /vol/pkg/20190803 --unprivileged
>
> I remove /usr/pkg/bin and /usr/pkg/sbin from PATH and instead add
> /vol/pkg/20190803/bin and /vol/pkg/20190803/sbin (before /usr/sbin).
>
> When installing a single package from its source directory, everything
> goes into the right place. But I noticed that calling
>
> $ pkg_chk -aun
>
> in /vol/pkgsrc/20190803/pkgsrc will pick up both the pkgchk.conf in
> that directory, but also /usr/pkgsrc/pkgchk.conf. This is easily fixed
> using "-C". In addition, I get "has binary package", because pkg_chk
> detects them in /usr/pkgsrc/packages.

If the pkg_chk "binary" compiled in /vol/pkg/20190803 looks in /usr/pkg
at all, I'd say that's a bug, and patch welcome.

I would not be surprised if you find several such bugs, but squash on!

> According to pkg_chk's
> manpage, the default path for binary packages is PACKAGES if PKGSRCDIR
> is available. These are
>
> $ bmake show-var VARNAME=PACKAGES
> /export/dk3/pkgsrc/20190803/pkgsrc/packages
> $ bmake show-var VARNAME=PKGSRCDIR
> /export/dk3/pkgsrc/20190803/pkgsrc
>
> i.e. (although symlink-resolved) the correct paths.

Seems like those should be bound at build time.

> I use pkg_chk with "-s" anyway, but this leaves me wondering if there
> are other situations where the two pkgsrc installation might get mixed
> up. Or are these bugs only in pkgtools/pkg_chk? Does anybody use such
> a scenario?

My impression is that people often use multiple trees.  I suspect that
you will not have too many problems.

The big hint is to use bmake from the new prefix, because it has the new
prefix baked in, but you already are doing that.


Home | Main Index | Thread Index | Old Index