Jason Bacon <outpaddling%yahoo.com@localhost> writes:
I'm having two problems following all this.
Upon closer inspection, it might not be a terrible idea to rpath
/usr/lib64/liblzma.so into pkg_install. It's from the xz package, not
xz-devel, and it cannot be removed because systemd depends on it.
It seems obvious that if you have a machine with a given configuration,
and then you either bootstrap pkgsrc or build packges, then they are
only guaranteed to work if the same "base system" packages are installed
later. This doesn't seem to be about pkg_install and xz. Given how
GNU/Linux has fine-grained packages in base, it seems the only two sane
things are:
1) document a minimal set of packages, and configure pkgsrc to prefer
pkgsrc for everything it can
2) expect the user to have the set of installed packages under CM, and
for binary package sets, document this set, and probably provide a
script to check it
Why is this situation special?
I think we still have the issue that lzma support in pkg_install
depends on the presence of Yum's xz-devel during bootstrap. That
should probably at least be documented.
That is unsurprising; given the GNU/Linux custom of foo/foo-devel, it
seems obvious that wtihout the -devel package a package is not usable to
build against.
As for rpath, arguably that should be in the pkg-config file found when
base liblzma is chosen. Actually I do't see why /usr/lib64 needs to be
in rpath at all, given that this is surely default on GNU/Linux systems,
an I don't follow you talking about rpath to a particular so.