-
Notifications
You must be signed in to change notification settings - Fork 38
Update and fix docutils-py #935
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
|
Think I got things mixed up with the existing naming scheme, which actually ends up as The 1.18.1 version was an option to have all variants in the same version, but if |
I'll have a 10.14 machine available next week (currently 12.6). I can work on this then. @clepple do you know any issues with updating docutils-py? |
@nieder TBH, I'm still a little ways away from being able to test this myself (had issues reinstalling Fink on a 10.15 box), but I was mainly tracking docutils for Trac and Django, and the latter seems to be better handled by Python virtualenvs (IMHO). The only fixed dependencies I found by running @dhomeier thanks for putting this PR together! |
@clepple thanks for checking the dependent packages; I also found I managed to get a 17.7 system up after all with python34 and python35 test builds and found
I am proposing, in the last commit, to switch to install all other scripts as |
As long as the change of the package-specific bin program naming scheme (57560f9) allows clean upgrade (existing bin/rst2html link automatically updates to the new-named target), I'm not concerned about it. We don't have a guideline about how to name those sorts of variant-specific files that are completely handled by update-alternatives magic. Using --slave certainly seems cleaner, and it's also sensible to keep a suite of tools in sync, so again if it doesn't confuse u-a during upgrades, it's just maintainers'-choice. |
At first glance this looks good, since I can't install the old version I can not test upgrade path for it. Can we get this into master? |
Anyone?? We really need docutils as it's builddep for lots of packages. Anyone able to test these packages with an upgrade path against the current versions? |
|
so build is failing for python 3.9, couldn't even test to upgrade back to using pkg_type over top of type_raw |
Googling around, it might be because docutils/ contains a python module 'io' that masks a python-core module of the same name, a core module that is also involved in error reporting. So it crashes because it can't even report the error properly. The masking is because PYTHONPATH contains 'docutils'. I think the python scripts and modules import |
Yes, absolutely right – apparently forgot to push that change while this was still in review. |
|
Doh, should not play around with the suggestions menu at this time of night! |
@dhomeier py39 worked though. |
Hmm, apparently changing the naming scheme is not causing problems here, but the master-slave setup does.
but this will fail in turn when updating the new package version again, as then there is only the master alternative
and even with the
I am out of my update-alternatives wisdom here, so unless someone still has an idea, I'd revert this change and continue to install all links independently. |
I added
Then
I think the new docutils-py is going to need a |
Oops. missed the previous comment by @dhomeier . I still need to read through it. |
Something like this:
This worked for me in updating docutils-py310 cleanly from 0.14, with the correct final symlinks. Have not tried it with a different lower py3x going to py310 yet. |
I almost tried something like that, but thought at that point the actual files from the previous package version would already have been removed...
I am afraid that is the critical point – there will be no
Actually should suffice to just remove |
The existing docutils-py.info only removes the symlinks when it's not an upgrade, so we need to be explicit in the new PreInstScript that we don't care what the old version did, we really want to delete the old symlinks.
I just noticed that 0.18.1 and 0.19 here have different u-a schemas. Do we want 0.19 to have 1 master w/ many slaves as well? That should be easier for maintenance, but what happens if the file list changes (eg a slave program gets removed upstream)? |
Yes, that was actually the idea; I just had not pushed those changes in 0.19 (nor the ones for 0.20.0, which is out in the meantime). And 0.19+ has a |
@dhomeier as soon as you have commits I can test them. |
@dhomeier are there any more commits that you have not yet pushed? |
@dhomeier ping on commits you said you had to make 0.19 (and 0.20?) a master docutils + slaves |
Fixes #931 using the latest available upstream versions for Python up to 3.10 and < 3.7, respectively.
I have not had a recent system with the older Python versions available to test the 1.18.1 package on.
The point of failure seems to have been adding
docutils/utils
to the localPYTHONPATH
. This overshadowed system modules likemath
, and I don't see it required – the local utils versions are already imported with the their relative path, e.g. asfrom docutils.utils import math
.