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