Please find a patch to www-apps/trac-1.0.3 ebuild to bring the following enhancement to current ebuild: - Drop python 2.6 support as unsupported by Gentoo since 2014-04-28 - Drop DISTUTILS_SINGLE_IMPL=Yes to let install cgi files for multiple python versions - Adjust DEPEND to stick on upstream recommendation - Add a markdown USE flag - Add a highlight USE flag - Support FEATURES=test, actually working with all USE flag and dependencies set - Drop DISTUTILS_NO_PARALLEL_BUILD as not supported anymore by Gentoo - Use python_doscript in a python_install() to install every cgi with the correct libexec wrapper and make the cgi usable by the best python version. I don't use python_install_all so the cgi available for other python version than only the best one. This is also the reason for dropping DISTUTILS_SINGLE_IMPL - Use webapp_pkg_postinst to let some info to users on how to update - Reproducible: Always
Created attachment 395478 [details, diff] trac-1.0.3.ebuild.patch
I incorporated some of your changes into trac-1.0.4. Some comments: - I don't understand the use case for dropping SINGLE_IMPL. IMO the SINGLE_IMPL is expressly designed for the sort of application use case we have here, and installing for multiple Python versions only makes sense for libraries. - I don't see much value in adding dependency specificity when we only have compatible versions in the tree. The ebuild very much lives in the context of the Portage tree. - Renamed the markdown USE flag to restructuredtext, since markdown isn't actually what is enabled here.
Also, thanks for the suggested changes!
(In reply to Dirkjan Ochtman from comment #2) > I incorporated some of your changes into trac-1.0.4. Thanks ! > Some comments: > > - I don't understand the use case for dropping SINGLE_IMPL. IMO the > SINGLE_IMPL is expressly designed for the sort of application use case we > have here, and installing for multiple Python versions only makes sense for > libraries. Because today trac support python 2.5, 2.6 and 2.7. Gentoo only support python:2 2.7 but trac may support python 3 in a few months, so why only limit to one release one more that one could be (is the case of using mod_python). > - I don't see much value in adding dependency specificity when we only have > compatible versions in the tree. The ebuild very much lives in the context > of the Portage tree. Understood > - Renamed the markdown USE flag to restructuredtext, since markdown isn't > actually what is enabled here. Fine with that.
> > - I don't see much value in adding dependency specificity when we only have > > compatible versions in the tree. The ebuild very much lives in the context > > of the Portage tree. > > Understood So the same should apply to dev-python/Babel depend right ? The minimum gentoo version in tree is 0.9.6 and trac ebuild require >=0.9.5. About postgres USE flag, why not use request SLOT=2 for dev-python/psycopg instead >=2 ?
(In reply to Bertrand Jacquin from comment #4) > Because today trac support python 2.5, 2.6 and 2.7. Gentoo only support > python:2 2.7 but trac may support python 3 in a few months, so why only > limit to one release one more that one could be (is the case of using > mod_python). Why do you want that? Just because you can is not a very good reason. (In reply to Bertrand Jacquin from comment #5) > So the same should apply to dev-python/Babel depend right ? The minimum > gentoo version in tree is 0.9.6 and trac ebuild require >=0.9.5. Yes, but that was actually useful at some point. You added things that will never be useful. I could have cleaned up the Babel thing, but I prefer to keep changes minimal. > About postgres USE flag, why not use request SLOT=2 for dev-python/psycopg > instead >=2 ? Because I suspect that psycopg-3.x will be largely backwards compatibly with psycopg-2, so there's no reason to exclude it.
(In reply to Dirkjan Ochtman from comment #6) > (In reply to Bertrand Jacquin from comment #4) > > Because today trac support python 2.5, 2.6 and 2.7. Gentoo only support > > python:2 2.7 but trac may support python 3 in a few months, so why only > > limit to one release one more that one could be (is the case of using > > mod_python). > > Why do you want that? Just because you can is not a very good reason. trac is almost a library (used by cli trac{d,-admin} or mod_python) so why should we limit the usage to only one release ? Also, what about the proposed test changes ?
