Your message dated Wed, 24 Feb 2016 12:51:03 +1100 with message-id <20160224015026.GA27307@latanatop> and subject line Re: Bug#815631: sphinx: Use alternatives to provide scripts under /usr/bin has caused the Debian Bug report #815631, regarding sphinx: Use alternatives to provide scripts under /usr/bin to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 815631: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815631 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Source: sphinx Severity: normal Dear Maintainer, I have recently needed to use a python3-only sphinx build process on a system with both python-sphinx & python3-sphinx co-installed. IMHO co-installation could be a little cleaner and easier if sphinx: - Used update-alternatives to provide /usr/bin/sphinx-* in a configurable way. (e.g similar to how docutils handles this problem). This could use the current script installation path under /usr/share/sphinx/scripts/python*/ - Or, installed binaries under /usr/bin with the suffix '3', i.e. install /usr/bin/sphinx-build3. (modelled after pip/pip3 & nosetests/nosetests3 and other similar examples) - Or, a combination of both these, where python-sphinx and python3-sphinx install /usr/bin/sphinx-*{2,3} respectively, and update-alternatives is used to provide /usr/bin/sphinx-* without prefix. Is there any reason that one of these approaches have not been taken? I'm relatively new to Debian packaging so there may be subtlety here I'm missing. I'm happy to have a go at implementing a solution to this myself, given guidance as to the best option to implement (if any). Cheers, Kevin P.S., I know one can always do /usr/share/sphinx/scripts/python3/sphinx-build as a workaround. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (400, 'unstable'), (300, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) --- Kevin Murray 0xA4B4EE6A
--- End Message ---
--- Begin Message ---Hi Dmitry, On 22:05 23/02, Dmitry Shachnev wrote: > Yes, in case it's hardcoded, you probably need to either patch Makefile or > execute sphinx-build from debian/rules by hand (and bug your upstream about > using configurable Make variables like in Sphinx-generated ones). > Shall do, thanks > > *However*, there is a supplementary issue: AFAICT, which package provides > > the > > /usr/bin/sphinx-* scripts depends on the order of installation. To me this > > sounds a little off, but I'm not sure. What is your opinion of this? > > No, it shouldn't depend on the order of installation. If the Python 2 version > is present, it's used, otherwise the Python 3 one. > > This is mostly for compatibility with old Python 2 only stuff… > That makes sense, yes. Closing this bug, thanks for your help & patience! Cheers, K --- Kevin Murray 0xA4B4EE6A
--- End Message ---
_______________________________________________ Python-modules-team mailing list Python-modules-team@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
