Re: Issues with using python37

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

John Klos <john%ziaspace.com@localhost> writes:

>>  A) For an installed package pyNN-foo or similar, extract NN and pass
>>  it as a version variable into the make replace.  This will enable
>>  pkg_rr, once such a package is selected, to replace it, in the case
>>  where NN isn't default
>
> This would work, but it wouldn't facilitate the move from Python27 to
> 37, which is what I think is going on here.

It solves the issue of updating pyNN-foo packages for NN not default.
Otherwise, having pyNN-foo leads to trying to rebuild pyDD-foo, for DD
the default.  This has been showing up with default 27 when there are
some 3x packages.

>>  C) The other is that make replace in general has a hard time for some
>>  kinds of changes.  One example is moving entries from a package's
>>  PLIST to the PLIST of a package that it (newly or already/still)
>>  depends on.  Here, I don't think this is part of the problem, but it's
>>  hard to be sure.
>
> This is where a full delete of a package and several if not most
> dependencies, then a reinstall of the root package is necessary. I've
> run in to this, but it escapes my memory what required this.

Typically

  foo has a big PLIST

  foo-lib is added, foo depends on it, and a lot of the PLIST entries
  are put into foo-lib.

Then, building foo depends on foo-lib, and the install of foo-lib fails
because it conflicts with the old foo's PLIST.

>> Reading the code and your log, I think the issue is that py37-expat
>> got added to REPLACE_TODO, even though it isn't installed
>
> Exactly. py27-expat was installed for devel/glib, and now devel/glib
> wants py37-expat.

Not exactly...    REPLACE_TODO is the set of packages which need to be
replaced.  Just because a package that needs to be replaced depends on
some other package, does not put that dependency in the must-be-replaced
list.  It is very normal for packages being replaced to have
dependencies that are not installed and that has generally been fine.
It happens always if people prune the not-manually-installed packages
(which is fine) because that deletes things like bison etc.

>> To test a theory that could lead to fixing B:
>>
>>  Try changing the abort on line 422 to an echo, or to error instead of
>>  abort and use -k.  I am inclined to s/abort/error/ here, but I'd like
>>  to hear how it goes.
>
> This still stops with this error:
>
> *** pkg_chk reports the following packages need replacing, but they
> are not installed: py37-dns

Well, that sounds like progress, and we have found the next bug.

If pkg_chk actually says py37-dns needs replacing, and it is not
actually installed, then that sounds like a bug to fix in pkg_chk.

But, you could change that to error from abort, too.

> E is good for most of my machines, but for that machine which lists 22
> packages which are "not installed", hardly.

Surely you can pipe that into a shell script that does the replace :-)

> On the other hand, I could make replace all 22 of them with a simple
> script. But what's the best fix to tell other pkgsrc users?

The best fix is to fix the bug in pkg_chk, if there is indeed one.  I
have staged the workaround to pkg_rr to not object to not-installed
packages at PKGPATH extraction time and will commit it, since it seems
it helped.