[[ I tried sending this to gnats-admin, but it hasn't appeared yet, and
in any case folks here might have answers or suggestions too. ]]
At Wed, 17 Apr 2019 23:32:40 +0100, Jonathan Perkin <jperkin%pkgsrc.org@localhost> wrote:
Subject: Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built pkg_summary)
>
> While pkgin shouldn't crash and should be able to handle bad input, it
> should be pointed out that this use-case is not expected to work at all,
> and any fix will simply enforce that. Your pkg_summary files should be
> generated from binary package files, not installed packages.
Hmmm... OK, so how should I generate the pkg_summary file for my limited
archive of locally built binary packages?
I couldn't find much info anywhere about handling the server-side of
things for pkgin, so I RTFM'ed and just did what it says in
pkg_summary(5):
The pkg_summary file can be generated using the pkg_info(1) −X option.
For example, the following will list this data for all installed pack‐
ages:
pkg_info ‐X ‐a
And I hoped that a file of the same name was of the kind that pkgin
would be happy to use.
Pkgin did seem to happily suck up the file, and "pkgin avail" gives me a
nice list corresponding to all the binary packages I should have
available. It's just the attempt to install one of them that failed.
I.e. there are binaries for all the installed packages in PKG_PATH --
that's the point, after all, as I am trying to use pkgin to install
those binaries on other local systems. (Indeed I now rely on the way
pkgsrc uses DESTDIR to create a binary package that's then installed as
the last step, even on the build machine.)
(and yes, PKG_PATH is set when I run "pkg_info -X -a", if that matters)
One caveat I have locally is that these binary packages may not all for
the same OS version and/or they may not all be in the same PKG_PATH
location, since it is -current, and I've built different packages at
different times while upgrading the OS from time to time (and though I
often use pgk_rolling-replace with its '-B' option on the build machine,
that doesn't seem to find absolutely everything that's not for the same
OS version and rebuild it).
So, I'm not sure if I should be simply linking together all the
compatible OS version binary package directories, or not. With pkg_add
I can't put multiple repositories in PKG_PATH, and presumably not for
"pkg_info -X" either, though it is hinted that repositories.conf can
contain a list of locations, though it's not clear if there can only be
one per $arch and/or $osrelease, nor is it clear what happens if
different installed packages were built for different (but nominally
compatible) $osrelease values. (The issue for me is that I'll likely
never manage to build everything I want all together at once with the
exact same OS release -- and I don't want to care about this as long as
the installed binaries run, and after all that's part of the point of
using NetBSD is that the ABI is stable for the most part, and even if
I've built packages on an old release that needs a COMPAT option, I
might want to include them in the stable of binary packages that I make
available for pkgin. I only really want to use pkgin for its ease of
managing upgrades, since for the initial installs it is not much
different for me to just use pkg_add directly, provided I really can
start with an empty /var/db/pkgin database and have it rebuilt to
account for such manually installed packages.)
--
Greg A. Woods <gwoods%acm.org@localhost>
+1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpuH4OnPrwWQ.pgp
Description: OpenPGP Digital Signature