tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Issues with using python37



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

> Try this:
>
> Install devel/glib2, then install mailman, which in turn installs
> py27-expat.
>
> Then run pkg_rolling-replace -u:
>
> RR> Tsorting dependency graph
> RR> Selecting glib2 (devel/glib2) as next package to replace
> RR> Checking if glib2 has new depends...
> RR> glib2 has the following new depends (need to re-tsort):
> rr> [python37 py37-expat libtool-base gmake pkgconf]
> RR> Tsorting dependency graph
> pkg_info: can't find package `py37-expat'
> *** Couldn't extract PKGPATH from installed package py37-expat
> *** Please read the errors listed above, fix the problem,
> *** then re-run pkg_rolling-replace to continue.
>
> How do we escape this versioning hell?

There are multiple things lurking here.

One is that pkg_rr should deal with pyNN- packages better.  There are
I think at least two, maybe three parts to this:

  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

  B) Either make the info used to denote packages be a pair of
  PKGNAME/PKGPATH, or decide that if PKGNAME doesn't map to an installed
  package, then it can be ignored.

  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.



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

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.

To work around the issue, three suggestions

  D) build and install py37-expat.  Set automatic=YES manually if you care
  about that.

  E) go to devel/glib2 and type make replace.  If you replace things in the
  wrong order, more or less nothing terrible should happen -- you might
  just build things more times than an optimal order would have.

  F) set up pbulk, build all your packages, remove and reinstall, and start
  over in the brave new world of py37

I would do E.


Home | Main Index | Thread Index | Old Index