Re: [Slackbuilds-users] six and python3-six
On Mon, 29 Oct 2018, B Watson wrote: Do we need separate six and python3-six builds? Right now, six will build & install python3 support if python3 is installed on the build box. python3-six is identical, except (a) it requires python3 in the .info file and (b) it builds only the python3 stuff. I'm a Python end-user and support the idea of having one build that supports both Python2 and Python3. All my new code is Python3 but many applications remain bound to Python2. It will take a while for everyone to migrate to Python3. Rich ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] six and python3-six
On 2018-10-29 5:44 a.m., Rich Shepard wrote: On Mon, 29 Oct 2018, B Watson wrote: Do we need separate six and python3-six builds? Right now, six will build & install python3 support if python3 is installed on the build box. python3-six is identical, except (a) it requires python3 in the .info file and (b) it builds only the python3 stuff. I'm a Python end-user and support the idea of having one build that supports both Python2 and Python3. All my new code is Python3 but many applications remain bound to Python2. It will take a while for everyone to migrate to Python3. For what it's worth, when 15.0 is released, I strongly advocate that Python SlackBuilds cover both Python 2 and 3 together in the same script - just like Pat is doing on current now. Yes, there are few cases where this won't be possible due to incompatibilities (for example IPython needs different versions for Python 2 and Python 3), but those are exceptions. For 14.2, there are several approaches being taken depending on the script maintainer, including various types of support for Python 3 in a Python 2 build script or having two scripts, one each for 2 and 3. My opinion is that we probably don't want to rock the boat too much during 14.2's lifetime but when we do switch to 15.0, I expect to see quite a bit of change in the Python SlackBuilds landscape. That being said, I have added *mandatory* Python 3 support to a few of my SlackBuild scripts to gauge whether it might make sense to start the conversion earlier (e.g. https://git.slackbuilds.org/slackbuilds/commit/?id=1ffc4da77ce21b851bb6dbb8fe01638a8b8d411b). So far no complaints. It's 2018 ... who still objects to having Python 3 installed? ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
[Slackbuilds-users] liblinebreak and/or libunibreak
liblinebreak's homepage at http://vimgadgets.sourceforge.net/liblinebreak/ says: Deprecation Notice: Liblinebreak has been superseded by libunibreak ...and we already have a build for libunibreak. I grepped the .info files, and nothing lists liblinebreak as a dependency. Unfortunately, liblinebreak and libunibreak conflict: they both install /usr/include/linebreak.h and /usr/include/linebreakdef.h, with different contents. Easiest solution here would be to remove liblinebreak. If that's not desired, the 2nd easiest solution would be to add text to the READMEs for liblinebreak and libunibreak stating that they conflict with each other. The 'proper' solution would be to modify one or both builds so they don't conflict. libunibreak uses pkg-config, so its includes could be moved to e.g. /usr/include/libunibreak and its .pc file modified to point there. Only one SBo build (fbreader) depends on libunibreak, so testing the modified build wouldn't be a lot of work. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/