On 26.01.2017 03:44, Jesus Cea wrote: >> Nothing is enforced, there are several ways to submit patches: >> - IRC (FreeNode #pkgsrc) >> - Problem Report (PR) via netbsd.org >> - GitHub pull request in Joyent's pkgsrc repository >> - mailing list (here) >> - pkgsrc-wip >> - via a developer > > Well, I must say that I am completely stupid and spoiled by the nice > Mercurial version control system, but I have completely borked my github > clone of joyent/pkgsrc. I really hate git!. So many hours and effort > wasted... > > About "send-pr": > > """ > -> send-pr > bash: send-pr: command not found > """ > netbsd.org -> Support -> Report a bug > I will try to tunnel this thru Joyent. Let's see. > > The initial patch or many is here: > <https://github.com/joyent/pkgsrc/pull/457> > > Please, review and possibly apply in pkgsrc trunk and supported > branches. BTW, what is the support policy for pkgsrc?. Joyent only > supports 201xQ4 for three years. Everything else is only supported until > next pkgsrc release. What do you do?. > > This takes care of Python 3.x. After merging this, I will take care of > Python 2.7. I don't want to waste effort if this tiny, trivial but > important patch is ignored :-). > This patch looks good. We should for such changes producing new binary package bump PKGREVISION (but don't rediff the patch yourself just for that, it can be done when applied to pkgsrc by a developer). >> As of now, there is no a specific developer dedicated to maintaining >> Python in pkgsrc. > > I see :-). > >>> 4. When Python 2.7.14 is out, what would be the procedure to clean the >>> "unneeded" patches in pkgsrc?. >> >> Please just submit a patch. A patch can delete files. >> >>> Is this the right mailing list to discuss those issues?. >>> >> >> Yes. > > Thank you. > > PS: Seems like currently pkgsrc can not have several python 3 versions > installed at the same time, because they conflict with > "/opt/local/bin/python3". I think this should be solved, having several > versions of Python at the same time is regular business. "python3" could > be replaced by a tiny program that launch the highest version available, > while an user can specify a particular version typing "python3.4" or > "python3.5". > > This is really useful to, for example, ease migration or just having new > services running current Python and old services running last year version. > This is definitely true. It also makes harm as some packages work only with certain range of Python 3.x. Another thing that annoys me with Python is "no-nis". It might be culprit that NetBSD installs YP/NIS headers for MKYP=no distribution, Python pretends that YP/NIS is supported but it's not. I'm not aware about other systems, but the living ones should never generate "no-nis" - so fixing NetBSD (and other OSes if applicable) is required. However there are currently more crucial issues, notably the number of local patches is high. > In my old Solaris 10 environment I have the following. Note Python 2.3 > and 3.0, for instance. Dinosaurs :-) > > """ > [root@babylon5 /]# ls -la /usr/local/bin/python* > lrwxrwxrwx 1 root root 7 Dec 26 00:03 /usr/local/bin/python -> python2 > lrwxrwxrwx 1 root root 9 Dec 26 00:03 /usr/local/bin/python2 -> > python2.7 > -rwxr-xr-x 1 root root 3108840 Apr 24 2008 /usr/local/bin/python2.3 > -rwxr-xr-x 1 root root 3340612 Apr 24 2008 /usr/local/bin/python2.4 > -rwxr-xr-x 1 root root 7796 Mar 14 2008 /usr/local/bin/python2.5 > -rwxr-xr-x 1 root root 1424 Mar 14 2008 /usr/local/bin/python2.5-config > -rwxr-xr-x 1 root root 9156 Nov 30 2012 /usr/local/bin/python2.6 > -rwxr-xr-x 1 root root 1424 Nov 30 2012 /usr/local/bin/python2.6-config > -rwxr-xr-x 1 root root 9152 Dec 26 00:01 /usr/local/bin/python2.7 > -rwxr-xr-x 1 root root 1687 Dec 26 00:03 /usr/local/bin/python2.7-config > lrwxrwxrwx 1 root root 16 Dec 26 00:03 > /usr/local/bin/python2-config -> python2.7-config > lrwxrwxrwx 1 root root 9 Dec 28 02:22 /usr/local/bin/python3 -> > python3.5 > -rwxr-xr-x 1 root root 10276 Apr 22 2009 /usr/local/bin/python3.0 > -rwxr-xr-x 1 root root 1401 Apr 22 2009 /usr/local/bin/python3.0-config > -rwxr-xr-x 1 root root 12444 Jun 13 2011 /usr/local/bin/python3.1 > -rwxr-xr-x 1 root root 1401 Jun 13 2011 /usr/local/bin/python3.1-config > -rwxr-xr-x 2 root root 13224 Jun 16 2013 /usr/local/bin/python3.2 > lrwxrwxrwx 1 root root 17 Apr 12 2012 > /usr/local/bin/python3.2-config -> python3.2m-config > -rwxr-xr-x 2 root root 13224 Jun 16 2013 /usr/local/bin/python3.2m > -rwxr-xr-x 1 root root 1884 Jun 16 2013 /usr/local/bin/python3.2m-config > -rwxr-xr-x 2 root root 13292 Mar 13 2014 /usr/local/bin/python3.3 > lrwxrwxrwx 1 root root 17 Mar 13 2014 > /usr/local/bin/python3.3-config -> python3.3m-config > -rwxr-xr-x 2 root root 13292 Mar 13 2014 /usr/local/bin/python3.3m > -rwxr-xr-x 1 root root 1978 Mar 13 2014 /usr/local/bin/python3.3m-config > -rwxr-xr-x 2 root root 12884 Feb 27 2015 /usr/local/bin/python3.4 > lrwxrwxrwx 1 root root 17 Feb 27 2015 > /usr/local/bin/python3.4-config -> python3.4m-config > -rwxr-xr-x 2 root root 12884 Feb 27 2015 /usr/local/bin/python3.4m > -rwxr-xr-x 1 root root 3021 Feb 27 2015 /usr/local/bin/python3.4m-config > -rwxr-xr-x 2 root root 12696 Dec 28 02:21 /usr/local/bin/python3.5 > lrwxrwxrwx 1 root root 17 Dec 28 02:22 > /usr/local/bin/python3.5-config -> python3.5m-config > -rwxr-xr-x 2 root root 12696 Dec 28 02:21 /usr/local/bin/python3.5m > -rwxr-xr-x 1 root root 3040 Dec 28 02:22 /usr/local/bin/python3.5m-config > lrwxrwxrwx 1 root root 16 Dec 28 02:22 > /usr/local/bin/python3-config -> python3.5-config > lrwxrwxrwx 1 root root 14 Dec 26 00:03 /usr/local/bin/python-config > -> python2-config > """ > > What do you think about this?. Something to discuss about? > Definitely agree. This task was just non-trivial, as far as I remember there is need to rename shared libraries to versioned .so files. We manage to install and link against versioned Lua packages, so Python should be doable as well. Personally, I don't understand the difference between .including buildlink and marking a Python library as DEPENDS. It should be documented in the pkgsrc's manual. Thank you for your involvement!
Attachment:
signature.asc
Description: OpenPGP digital signature