Andreas Kusalananda Kähäri <andreas.kahari%icm.uu.se@localhost> writes:
> I'm syncing the pkgsrc source tree using syncthing, but so far I've had
> to keep the binary packages separate. The reason for this is that I
> have LOCALBASE as $HOME/sw on both systems, but $HOME differs. On one
> system it's "/home/therealme" and on the other it's "/home/theotherme".
> I have no say in what my user names are, and I'm not allowed to make
> changes outside of $HOME.
>
> I know that pkg_add allows me to specify a different installation prefix
> than what is recorded in the binary package ("-p"), but I'm used to
> using pkg_chk and pkg_rolling-replace to do bulk updates of packages,
> and I'd rather not have to manage package updates by hand with pkg_add.
Yes, but I don't see how it can really completely work, because the
prefix is often hardcoded into binaries for search paths, etc.
> As far as I know, there is no way to tell pkg_chk or pkg_rolling-replace
> to use a different installation prefix, is there?
As far as I know they both use the mk.conf-defined LOCALBASE.
But the real issue is "can I install a binary package built with one
definition of LOCALBASE into a different LOCALBASE and have it be 100%
correct", and I think the answer is no.
> What would be the best way to unify the binary packages on these
> systems?
Can you get the admins to make the same symlink on two machines into
your two places?
> I'm using
>
> PACKAGES=${PKGSRCDIR}/packages/${LOWER_OPSYS}-${OS_VERSION}-${MACHINE_ARCH}
>
> (as suggested by the pkg_chk manual, since I also sync the source
> tree with a couple of Darwin machines), and this resolves to
> "pkgsrc/packages/linux-2.6.32-x86_64/" under $HOME on both systems.
I would recommend having a mk.conf.local which is not synced, .included
by the synced mk.conf. Or just don't sync mk.conf. Then you have a
token that represents which prefix.
Attachment:
signature.asc
Description: PGP signature