On 02.05.2016 18:40, Reid Kleckner wrote: > On Sun, May 1, 2016 at 2:21 PM, Kamil Rytarowski via lldb-dev > <lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org>> wrote: > > It has been noted that LLDB installs its own copy of six.py > (third_party/Python/module/six/six.py) that conflicts with a standalone > one lang/py-six (path in pkgsrc). > > Could we reuse an external version shipped with a system? Alternatively > are there plans to migrate to Python 3 and remove need for it? > > How to address this conflict cleanly? > > > LLDB should continue to ship its own copy of six.py. It's a single 900 > line source file. Avoiding this duplication is not worth the headache of > asking users to install dependencies. I can't imagine a world where > checking in your own copy *wasn't* the intended distribution model for > six.py. >
I don't agree here, built in libraries have security and maintainability issues downstream. Correct packaging is about removing these builtin redundant libraries and link with upstream ones. And in case of a vulnerability (or other kind of bug) upgrade a dependency for everybody at once. > I'm sure LLDB would take patches to mitigate the namespace conflict. For > example, LLDB could do something like "from lldbutils import six" > instead of "import six", or we could avoid putting it on sys.path if we > notice a system installation of six. Dynamic detection of system capabilities isn't reproducible. Also there is a scenario of installing lldb and later one of other packages installing global py-six.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
