where should we put private libraries
Hello, I am working on the dials[1] package. This scientific software produce a bunch of python extension via boost python, but also a bunch of libraries, which are the common part of the python extension. when I package it, I moved the common library under the /usr/lib// directory. This way the extension can find them without problem. but then I have a lintian error about E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libann.so 30 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libasymmetric_map.so 31 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libcctbx.so 32 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libcctbx_sgtbx_asu.so 33 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libdxtbxspotfinder.so 34 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libiotbx_mtz.so 35 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libiotbx_pdb.so 36 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libiotbx_xplor.so 37 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/liblegacy_scale.so 38 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libmmtbx_masks.so 39 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libmmtbx_tls.so 40 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libomptbx.so 41 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/librstbx.so 42 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libscitbx_boost_python.so 43 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libscitbx_minpack.so 44 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libscitbx_slatec.so 45 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libsmtbx_refinement_constraints.so 46 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libspotfinder.so 47 E: dials: sharedobject-in-library-directory-missing-soname usr/lib/x86_64-linux-gnu/libxfel_mono_sim.so so my question is how can I solve this error. I thought about adding rpath to these libraries in order to move then under a private location /usr/lib/. But for this I need to add an rpath to all the extensions which use these libraries. The issue is that the current build system do not provide rpath for these libraries so I can not add one via chrpath. In your opinion, what is the best way to solve this ? thanks for your help Frederic [1] https://salsa.debian.org/science-team/dials [é] https://salsa.debian.org/science-team/dials/-/jobs/661523
Re: where should we put private libraries
On Sun, Apr 12, 2020 at 03:18:39PM +0200, picca wrote: > I thought about adding rpath to these libraries in order to move then > under a private location /usr/lib/. This looks like the correct way to solve this. > The issue is that the current build system do not provide rpath for > these libraries so I can not add one via chrpath. Well, ideally you need to fix the build system so that it sets the correct rpath directly. -- WBR, wRAR signature.asc Description: PGP signature
RE:where should we put private libraries
> > The issue is that the current build system do not provide rpath for > > these libraries so I can not add one via chrpath. > Well, ideally you need to fix the build system so that it sets the correct > rpath directly. I found patchelf whcih allows to add a rpath :)) So I just need to set the rpat for all the extensions and voila :) Cheers Frederic
Re: where should we put private libraries
> so my question is how can I solve this error. > I thought about adding rpath to these libraries in order to move then > under a private location /usr/lib/. But for this I need to add > an rpath to all the extensions which use these libraries. You should consider /usr/lib// if you want to make your package multiarch-safe. See: https://wiki.debian.org/Multiarch/Implementation#What_does_the_end_result_look_like.3F
RE:where should we put private libraries
> You should consider /usr/lib// if you want to make your > package multiarch-safe. And what about ? /usr/lib// whcih one is better ?
Re: where should we put private libraries
>> You should consider /usr/lib// if you want to make your >> package multiarch-safe. > > And what about ? > > /usr/lib// > > whcih one is better ? Have a look at the Debian policy at https://www.debian.org/doc/debian-policy/ch-opersys.html#s-fhs It explicitly mentions: > Applications may also use a single subdirectory under > /usr/lib/triplet.
PEP-517/PEP-518 Support In Debian
This being roughly the mid-point in the development cycle, I thought it might be good to see where we are in terms of future Python packaging developments. As I understand it, PEP-517 and PEP-518 are 'the future'. I took a look at the presence of pyproject.toml files in the Debian archive. There are currently 99 packages. Of those, only 28 specify a 'build-backend', which is required by 517/518 to be useful for building a package. 25 specify: build-backend = "setuptools.build_meta" (including setuptools) 3 specify: build-backend = "flit_core.buildapi" (including flit) If build-backend is not specified, the build system has to fall back to setup.py. I've recently package flit (just arrived in Testing) and written a flit plugin for pybuild that's pending review for merging[1]. I also packaged pep517 for our pip package, so that's available to support future Debian tool development in this area. For the moment, I guess we are in reasonable shape, but it might be useful to have a pybuild plugin to use PEP517/setuptools.build_meta in lieu of setup.py with setuptools/distutils when available. In the future, this will be the primary API and the sooner we start to use it, the better. Scott K [1] https://salsa.debian.org/python-team/tools/dh-python/-/merge_requests/12 signature.asc Description: This is a digitally signed message part.
py2removal: drop python-pytest by not running tests for python2 packages
Hello, python-pytest is blocking 18 packages from removal, most of them would be leaves once python-pytest is gone. so i was playing with the idea of tackling python-pytest removal by updating all its rdeps and not run unittests for the python2 binary (so dropping pytest and the other b-d* only used for tests). I know it's suboptimal (some python2 packages can still see updates until we're ready to drop them and running tests can still have value), but i think the cost/benefit ratio points towards removing python-pytest soon rather than wait. There are only 25 packages that would need updating, and most of them are in DPMT/PAPT. What do people think? Cheers, -- Sandro "morph" Tosi My website: http://sandrotosi.me/ Me at Debian: http://wiki.debian.org/SandroTosi Twitter: https://twitter.com/sandrotosi
Re: py2removal: drop python-pytest by not running tests for python2 packages
On Sunday, April 12, 2020 9:56:01 PM EDT Sandro Tosi wrote: > Hello, > python-pytest is blocking 18 packages from removal, most of them would > be leaves once python-pytest is gone. > > so i was playing with the idea of tackling python-pytest removal by > updating all its rdeps and not run unittests for the python2 binary > (so dropping pytest and the other b-d* only used for tests). > > I know it's suboptimal (some python2 packages can still see updates > until we're ready to drop them and running tests can still have > value), but i think the cost/benefit ratio points towards removing > python-pytest soon rather than wait. > > There are only 25 packages that would need updating, and most of them > are in DPMT/PAPT. Go for it. Scott K signature.asc Description: This is a digitally signed message part.
Re: PEP-517/PEP-518 Support In Debian
On Sun, Apr 12, 2020 at 10:32 PM Scott Kitterman wrote: > I took a look at the presence of pyproject.toml files in the Debian archive. > There are currently 99 packages. Of those, only 28 specify a 'build-backend', > which is required by 517/518 to be useful for building a package. Is there a tool that can report problems in pyproject.toml files? Either way I think that lintian needs to detect this particular issue. -- bye, pabs https://wiki.debian.org/PaulWise
Re: PEP-517/PEP-518 Support In Debian
On April 13, 2020 3:44:31 AM UTC, Paul Wise wrote: >On Sun, Apr 12, 2020 at 10:32 PM Scott Kitterman wrote: > >> I took a look at the presence of pyproject.toml files in the Debian >archive. >> There are currently 99 packages. Of those, only 28 specify a >'build-backend', >> which is required by 517/518 to be useful for building a package. > >Is there a tool that can report problems in pyproject.toml files? >Either way I think that lintian needs to detect this particular issue. Not that I know of, but I don't think it's time yet. They're non-build uses for pyproject.toml, so if build-backend isn't present, it just means that it isn't used for build reasons. The pep517 package (python3-pep517) can validate metadata generated based on pyproject.toml, but it spins up it's own environment using pip and does a package sdist build to do so. I don't think that's what you have in mind. In the pybuild plugin I did for flit, I do check for the correct build-backend when autodetecting if the plugin should be used. Using python3-toml it's a one liner. If we really want to head down rlthe path of checking, it ought to be simple enough to write. Scott K
