pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg/52755: lang/python27 needs comp.tgz to find shared libraries



The following reply was made to PR pkg/52755; it has been noted by GNATS.

From: Hauke Fath <hf%spg.tu-darmstadt.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: pkg-manager%NetBSD.org@localhost, gnats-admin%NetBSD.org@localhost
Subject: Re: pkg/52755: lang/python27 needs comp.tgz to find shared libraries
Date: Fri, 24 Nov 2017 12:20:28 +0100

 On 11/23/17 00:55, Pierre Pronchery wrote:
 > Many Python-based programs and packages will fail to work without the "comp"
 > set installed, since ctypes.util.find_library() will not find any library
 > without it being installed.
 
 So you are installing a programming environment (python), but 
 explicitely not the native toolchain. Then you find that some aspects of 
 the programming environment rely on native toolchain bits.
 
 While python's autohell build system is perfectly capable of finding the 
 system libraries, a runtime module (ctypes) is not, and relies on 
 external tools for the task. Looks like a python ctypes bug to me - have 
 you taken the issue upstream?
 
 >> Fix:
 > To work around the problem, install the "comp" set. However I do not
 > think we can expect users to have to install it. 
 
 Why? How is it unreasonable to expect the native toolchain around when 
 you install a programming environment?
 
 > I avoid installing it
 > as often as possible myself (notably for security reasons).
 
 Fun fact: The last "malware installation" I have seen in the wild was a 
 SIP scanner, implemented in - python.
 
 > I am not sure what the proper fix should be:
 > - let lang/python* depend on an implementation of lang/gcc
 > - adding a message when installing lang/python*
 
    - ask upstream to let ctypes fall back to a compile-time search path 
 to find its libraries. It does that on Windows and Mac OS X, already 
 <http://docs.activestate.com/activepython/2.5/python/lib/ctypes-finding-shared-libraries.html>.
 
 > I would clearly prefer the former.
 
 You refuse to install the comp set "because security", and then turn 
 around to build and install gcc (binutils rather, if you want 
 objdump(1)) for every python installation? Apart from the bloat and 
 churn this adds - how is it more secure?
 
 Cheerio,
 hauke
 
 -- 
       The ASCII Ribbon Campaign                    Hauke Fath
 ()     No HTML/RTF in email	        Institut für Nachrichtentechnik
 /\     No Word docs in email                     TU Darmstadt
       Respect for open standards              Ruf +49-6151-16-21344
 


Home | Main Index | Thread Index | Old Index