On Sat, 20 Apr 2019 at 07:16, Greg A. Woods <[email protected]> wrote: > > [[ 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 <[email protected]> > 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
I have always used cd /usr/pkgsrc/packages/All ; ( for i in *.tgz; pkg_info -X $i ) | bzip2 > pkg_summary.bz2 This gives me the older versions of packages as well, should I need them (and I do - e.g. qemu-3.1.0nb4.tgz was produced from wip/qemu-nvmm, whereas qemu-3.1.0nb5.tgz from emulators/qemu, a rather different one, ten times the size). I still get errors using this repo on occasion, usually some dependencies not caught for upgrade, so I have to examine the log file and first go through their update - again with pkgin - repeating the initial installation at the end. It is not ideal, but usable. I normally setup the repo to be accessed via anonymous ftp, but also via nfs. > > 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 <[email protected]> > > +1 250 762-7675 RoboHack <[email protected]> > Planix, Inc. <[email protected]> Avoncote Farms <[email protected]> -- ----
