Re: Problem using a second pkgsrc unprivileged

One possible way (not recommended, although I have used it in the past, a fairly long time ago) to try out new things in a completely different prefix:

Use 2 pkgsrc trees (say one stable, one head).

In the top of each pkgsrc tree, set different mk variables for that tree in a file called custom.mk - at least:

LOCALBASE= /usr/pkg/stable

PKG_DBDIR= ${LOCALBASE}.pkgdb

and

LOCALBASE= /usr/pkg/head

PKG_DBDIR= ${LOCALBASE}.pkgdb

In /etc/mk.conf, include a stanza that says:

.ifdef BSD_PKG_MK

.sinclude "${.CURDIR}/../../custom.mk"

.endif

Then play man and path games with /usr/pkg/{stable,head}/{bin,sbin} and LD_LIBRARY_PATH to invoke the right binary and library

***HOWEVER***, pkg_install tools have to know which prefix you mean (via PKG_DBDIR), and that involves using shell variables to tie in with the man variables there. I used to have an integrated shell/make setup, but these days - I just use a different VM for stuff like this

Best,

Alistair

On Sun, 25 Oct 2020 at 10:04, Greg Troxel <gdt%lexort.com@localhost> wrote:

Sad Clouds <cryintothebluesky%gmail.com@localhost> writes:

>> Connor McLaughlan <cont6pro3%gmail.com@localhost> writes:
>>
>> > One out of several usecases i have is to get some old kde3/qt3 stuff
>> > compiled and running.
>> > It will run in a clean old pkgsrc-tree, but i am unable to install
>> > those old libraries into a current pkgsrc-tree, due to file
>> > conflicts.
>>
>> You should be able to this. Lack of containers is a red herring, I
>> think. You may have to fix bugs, but it may also be that your only
>> real issue is BINPKGS.
>
> I don't think it's as simple as that. Some software is quite complex
> and can result in run-time conflicts. For example, you want to run V1.0
> and V2.0 of the same software at the same time. So you manage to
> install them in different locations, but you can't run two instances at
> the same time, because they share things like - log and db files, pid
> and lock files, IPC paths like unix sockets and shared memory, and so
> on. You need zones or containers, which could be emulated with chroot
> to some extent.

Sure, but for many things it is fine. Agreed it's a fair caution that
two pkgsrc prefixes do not make a VM.