Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built pkg_summary)

[David Holland <dholland-pbugs%netbsd.org@localhost>]

The following reply was made to PR pkg/54123; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built
 pkg_summary)
Date: Mon, 10 Jun 2019 05:29:13 +0000

 not sent to gnats (send bug traffic to gnats-bugs, not gnats-admin)
 
    ------
 
 From: "Greg A. Woods" <woods%planix.ca@localhost>
 To: NetBSD GNATS Administrator <gnats-admin%NetBSD.org@localhost>
 Subject: Re: pkg/54123 (crash trying 'pkgin upgrade' with locally built
 	pkg_summary)
 Date: Wed, 17 Apr 2019 21:49:47 -0700
 
 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>