Bug#584124: salome: fails to install (tries to overwrite '/usr/bin/display'

Andre Espaze andre.espaze at logilab.fr
Mon Jun 7 15:07:38 UTC 2010


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é






More information about the debian-science-maintainers mailing list