Re: new pkg_rr to semi-avoid python version lossage, recording python versions

[Greg Troxel <gdt%lexort.com@localhost>]

Rhialto <rhialto%falu.nl@localhost> writes:

> On Mon 29 Jul 2019 at 11:02:34 -0400, Greg Troxel wrote:
>> I looked at pkg_chk this morning, and concluded that long-term it's
>> probably best to reimplement the "for all installed packages, see if
>> they are out of date" logic, as pkg_chk is doing much more than pkg_rr
>> needs.
>
> Are you talking about changing pkg_chk here, or pkg_rr? My first
> interpretation was the former, but now I realise the latter is also
> possible.

My first thought was to fix pkg_chk, but then it seemed like that would
be hard.

The basic issue is that for each installed package there is PKGNAME, and
one can get PKGPATH, and then needs to add back in variables to cause
"make replace" in that PKGPATH to replace PKGNAME, instead of some other
PKGNAME.  An example is PKGNAME=py27-expat.

pkg_chk is doing a lot of things for a lot of cases, and thus
rototilling the basic data structures is more or less out of the
question, at least for me.

> Just for avoidance of doubt: I use pkg_chk directly (remove all outdated
> packages and their dependents, then install my wanted set of packages
> from binary packages).

I see.  I don't know how hard it would be to make that work.

> I have tried pkg_rr and pkgin a few times in the past, but somehow
> managed to run into corner cases that didn't seem to be handled just
> right. So I would prefer that a reduction of functionality of pkg_chk
> is avoided.

I am not proposing to reduce anything in pkg_chk.  I was merely
suggesting that I wouldn't improve it to handle pyNN-foo.

I would think that "pkgin fug" might do what you want, mostly, and that
if not it is probably a bug.   A preparatory "pkgin ar" might be just as
well.

pkg_rr is another beast; it runs into trouble if it tries to build a
package and that package won't build (often reported as "pkg_rr didn't
work", when really it did and the underlying package was not ok).   It
also fails to handle packages that can't be replaced because of files
moved along the dependency chain - there is no logic to realize this and
remove two, add two.

More spectacularly, it fails to replace multiversion packages that are
not the default version, and that's what I am trying to address.


If you end up with patches to improve pk_-chk, do post them and I think
people would be interested.