Bug#584124: salome: fails to install (tries to overwrite '/usr/bin/display'
Hi Adam, Are those libraries private to salome? (In other words, are you sure that no other package will be linked against them?) * If yes, there is no reason to provide libsalome5.1.3-0 and libsalome-dev packages, these libs are shipped by another package (python2.5-salome?) and can safely be moved into /usr/lib/salome/ * If no, they should indeed go into /usr/lib/ but name collisions will happen. Maybe the answer is a mix of both, some libs are private and some others are public. I was thinking the same thing. Back to André: are there libraries which are meant to be shared with other packages, or are they all private to Salomé? To my point of view, all librairies should be private to Salomé. I agree with the first solution, there is no need to provide libsalome* and python2.5-salome. BTW when looking at this issue, I found that python2.5-salome contains shared libraries, it thus must be arch:any and not arch:all. It also contains static libraries which can surely be dropped. BTW2, I wonder whether salome, python2.5-salome, libsalome5.1.3-0 and libsalome-dev could be merged into a single package (if all libs are private, of course). Indeed. There's still value in having a separate -common package, to reduce archive disk footprint. I'll first try to get the new paths working, then do this merger, and upload, then we can think about splitting things up differently. (core, extras, dev, test) Excellent. I saw anyway that you have just opened bug 584590 where we are going to try to solve that problem. Best regards, André -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584124: salome: fails to install (tries to overwrite '/usr/bin/display'
On 2010/6/3 Adam C Powell IV wrote: [...] Unfortunately this will likely require the use of rpath to get to the libs, this is frowned upon in general in Debian. [...] Are those libraries private to salome? (In other words, are you sure that no other package will be linked against them?) * If yes, there is no reason to provide libsalome5.1.3-0 and libsalome-dev packages, these libs are shipped by another package (python2.5-salome?) and can safely be moved into /usr/lib/salome/ * If no, they should indeed go into /usr/lib/ but name collisions will happen. Maybe the answer is a mix of both, some libs are private and some others are public. BTW when looking at this issue, I found that python2.5-salome contains shared libraries, it thus must be arch:any and not arch:all. It also contains static libraries which can surely be dropped. BTW2, I wonder whether salome, python2.5-salome, libsalome5.1.3-0 and libsalome-dev could be merged into a single package (if all libs are private, of course). Denis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584124: salome: fails to install (tries to overwrite '/usr/bin/display'
Hi Denis, On Thu, 3 Jun 2010 12:02:00 +0200 Denis Barbier wrote: [...] Unfortunately this will likely require the use of rpath to get to the libs, this is frowned upon in general in Debian. [...] Realized that this shouldn't be necessary, as runSalome sets LD_LIBRARY_PATH. I'm working on testing this... Are those libraries private to salome? (In other words, are you sure that no other package will be linked against them?) * If yes, there is no reason to provide libsalome5.1.3-0 and libsalome-dev packages, these libs are shipped by another package (python2.5-salome?) and can safely be moved into /usr/lib/salome/ * If no, they should indeed go into /usr/lib/ but name collisions will happen. Maybe the answer is a mix of both, some libs are private and some others are public. I was thinking the same thing. Back to André: are there libraries which are meant to be shared with other packages, or are they all private to Salomé? BTW when looking at this issue, I found that python2.5-salome contains shared libraries, it thus must be arch:any and not arch:all. It also contains static libraries which can surely be dropped. BTW2, I wonder whether salome, python2.5-salome, libsalome5.1.3-0 and libsalome-dev could be merged into a single package (if all libs are private, of course). Indeed. There's still value in having a separate -common package, to reduce archive disk footprint. I'll first try to get the new paths working, then do this merger, and upload, then we can think about splitting things up differently. (core, extras, dev, test) -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#584124: salome: fails to install (tries to overwrite '/usr/bin/display'
Dear Denis, Your bug reflects a bigger problem with Salomé, which is namespace collisions with a potentially large group of packages. Denis Barbier noted this in a post to the ITP bug [1]. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457075#365 I'm testing a solution using bindir=/usr/lib/salome/bin libdir=/usr/lib/salome/lib (Salomé's defaults are /usr/bin/salome and /usr/lib/salome which don't follow Debian's convention). Right now the package keeps runSalome and killSalome in /usr/bin . Unfortunately this will likely require the use of rpath to get to the libs, this is frowned upon in general in Debian. The question is: what other binaries are meant for users to run directly, instead of being run by Salomé? And what libraries are meant to be linked by other packages, instead of just by the Salomé binaries? -Adam -- GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Engineering consulting with open source tools http://www.opennovation.com/ signature.asc Description: This is a digitally signed message part
Bug#584124: salome: fails to install (tries to overwrite '/usr/bin/display')
Package: salome Version: 5.1.3-8 Severity: grave Tags: sid Justification: renders package unusable Hi, First of all, thanks for having packaged Salome ! Unfortunately, on my system, it fails to install with the following error: Unpacking salome (from .../salome_5.1.3-8_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/salome_5.1.3-8_amd64.deb (--unpack): trying to overwrite '/usr/bin/display', which is also in package imagemagick 7:6.6.0.4-2 dpkg-deb: subprocess paste killed by signal (Broken pipe) Processing triggers for menu ... Processing triggers for desktop-file-utils ... Processing triggers for gnome-menus ... Errors were encountered while processing: /var/cache/apt/archives/salome_5.1.3-8_amd64.deb Cheers, Denis -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing'), (200, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages salome depends on: ii libboost-thread1.42.0 1.42.0-3 portable C++ multi-threading ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib ii libcos4-1 4.1.3-1omniORB CORBA services stubs ii libcppunit-1.12-1 1.12.1-1 Unit Testing Library for C++ ii libexpat1 2.0.1-7XML parsing C library - runtime li ii libgcc1 1:4.4.4-1 GCC support library ii libgl1-mesa-glx [libgl1] 7.7.1-2A free implementation of the OpenG ii libglu1-mesa [libglu1]7.7.1-2The OpenGL utility library (GLU) ii libhdf5-openmpi-1.8.4 1.8.4-patch1-2 Hierarchical Data Format 5 (HDF5) ii libmed1 2.3.6-2Library to exchange meshed data (F ii libmedimportcxx0 2.3.6-2Library to import old version file ii libomniorb4-1 4.1.3-1omniORB core libraries ii libomnithread3c2 4.1.3-1C++ threading library ii libopencascade-foundation 6.3.0.dfsg.1-4 OpenCASCADE CAE platform shared li ii libopencascade-modeling-6 6.3.0.dfsg.1-4 OpenCASCADE CAE platform shared li ii libopencascade-ocaf-lite- 6.3.0.dfsg.1-4 OpenCASCADE CAE platform shared li ii libopencascade-visualizat 6.3.0.dfsg.1-4 OpenCASCADE CAE platform shared li ii libopencascade-visualizat 6.3.0.dfsg.1-4 OpenCASCADE CAE platform library d ii libopenmpi1.3 1.4.1-3high performance message passing l ii libqt4-opengl 4:4.6.2-4 Qt 4 OpenGL module ii libqt4-xml4:4.6.2-4 Qt 4 XML module ii libqtcore44:4.6.2-4 Qt 4 core module ii libqtgui4 4:4.6.2-4 Qt 4 GUI module ii libsalome-dev 5.1.3-8Numerical simulation pre- and post ii libsalome5.1.3-0 5.1.3-8Numerical simulation pre- and post ii libscotch-5.1 5.1.8a.dfsg-2 programs and libraries for graph, ii libstdc++64.4.4-1The GNU Standard C++ Library v3 ii libvtk5.4 5.4.2-6Visualization Toolkit - A high lev ii libx11-6 2:1.3.3-3 X11 client-side library ii libxml2 2.7.7.dfsg-2 GNOME XML library ii libxt61:1.0.7-1 X11 toolkit intrinsics library ii omniorb4-nameserver 4.1.3-1Transitional package for the omniO ii python2.5 2.5.5-6An interactive high-level object-o ii python2.5-salome 5.1.3-8Numerical simulation pre- and post ii salome-common 5.1.3-8Numerical simulation pre- and post salome recommends no packages. Versions of packages salome suggests: ii salome-examples 5.1.3-8Numerical simulation pre- and post -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
