python3.10: bump version to 3.10.8.

[OscarL]

• Use "make altinstall".
• Documented problematic tests, and skipped the ones that hang/stall.
• Enable optimizations.
• Added a note regarding tests that invoke the crash dialog.

Running "hp --test python310" now gives the same results[*] for both non-optimized, and optimized builds, so let's just enable optimizations for 3.10.8.

[*] As there's some randomness involved in the test runs, YMMV.

Anecdotal/additional info:

Building and testing with "--disable-test-modules" might be considered? Python's docs read:

"The test package is meant for internal use by Python only."

And that those are used for regression testing mostly. See: https://docs.python.org/3/library/test.html#module-test

Personal experience: I got more consistent results with that flag enabled, than without it. I left it out, trying to avoid hiding problems (a.k.a.: failing silently. A big NO-NO in QA/QC), and because I assume that packaging Python counts as "internal use".

Typos on the commit message might or might not be addressed on follow up commits :-P

[OscarL]

I can patch the tests that require several GBs of free space in a follow up commit on this PR, to mimic Win and MacOSX behaviour (instead of just removing the tests). Edit: DONE.

Test runs with or without "--enable-optimizations" do not show noticeable changes in runtime, at least on my PC, and with the Python test cases, anyway.

I don't have enough experience on non I/O bound loads to judge performance issues.

[Begasus]

GLOBAL_WRITABLE_FILES should be moved up before PROVIDES (see: https://github.com/haikuports/haikuports/wiki/HaikuPorter-Guidelines#ordering)
Probably a remain from early recipes.

[OscarL]

GLOBAL_WRITABLE_FILES should be moved up before PROVIDES

Will do, thanks.

Maybe Haikuporter's strict mode should auto-check this and report an error, no? Just noticed that lint-new-recipes.sh that gets run here for new PRs calls haikuporter --lint, so I guess that's where this check should be.

(adding that to the ToDo list :-D)

[pulkomandy]

PROVIDES=" - python310$secondaryArchSuffix = $portVersion compat >= 3.10 > I think in this case there isn't anything to replace as there wouldn't be anything providing python310? Ok. I was assuming that on a situation like this: "package_X" requires "python310", but that got renamed to "python3.10", the package manager will see that no one provides "python310", BUT that the new "python3.10 guy" do replaces that. If that's not the case, keeping python310 on PROVIDES makes sense, but then.... what would be the purpose of adding a REPLACES section in cases like this one (as @korli suggested on that "rename Python 3.9 and make it the default one" change)... just as a reference / documentation thing?

I don't know if what you suggest works, sounds logical but I don't know. What I know works, is, when doing a pkgman full-sync, if a package replaces another, pkgman will be hinted to uninstall the old one and install the new one instead. If you want more details, these things are actually implemented by libsolv, the same dependency solver used by OpenSUSE, and I think the documentation will be there if there is any.

[OscarL]

Thanks for the pointers @pulkomandy!

From Libsolv's repo_haiku.cpp:

// TODO: Check whether freshens and replaces does indeed work as intended

Heh :-)

---

It seems "replaces" is basically a synonymous of "obsoletes" on libsolv's docs and code. And most of the "obsoletes" mentions seem to be regarding which packages should be uninstalled (as PulkoMandy schooled me about).

But then there's bits like this:

POOL_FLAG_NOINSTALLEDOBSOLETES

New versions of rpm consider the obsoletes of installed packages when checking for dependency,
thus you may not install a package that is obsoleted by some other installed package, unless you
also erase the other package.

That seem kinda like a "don't install X, because Y already provides that" to me. But I don't know how relevant is that to Haiku (considering the RPM mention).

(I tried following the trails of ->obsoletes through libsolv's code, but got lost pretty fast :-P)

I guess at some point I should try to come up with some ".hpkg" test-cases, and see what's what.

As that will take me a while... I guess I'll follow @Begasus suggestion for this recipe, unless someone else objects.

Thanks.

[OscarL]

Latest push addresses Begasus' suggestions. Built & tested on both 32 and 64 bits (hrev56578+10).

The "TEST" section got pretty verbose, but at some point that will come in handy when trying to address some of the remaining issues with this port.

I still get some occasional "random" hangs running hp --test python3.10 (on test_subprocess, for example, sometimes only after its re-run), but repeatable test runs are now more attainable than before :-D