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

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On Sat, 20 Apr 2019 at 07:16, Greg A. Woods <woods%planix.com@localhost> 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 <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

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 <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>



-- 
----