On 18/02/15 10:49, Dennis van Dok wrote:
> I'm maintaining a framework package (lcmaps) with several plugins that
> traditionally install under /usr/lib/lcmaps. With the move to debhelper
> 9, the default for dh_auto_configure is to pass
> --libdir=/usr/lib/x86_64-linux-gnu which changes the plugin path.
Is multiarch actually beneficial to you for lcmaps / would it ever make
sense to have more than one architecture's instance of it installed?
If not, you can use something like "dh_auto_configure --
--libdir=/usr/lib" to take it back to the single-arch path. This is what
telepathy-mission-control-5 does: it is a daemon, and only has a shared
library at all to be able to support plugins in a Windows-compatible way
(i.e. with no object having unresolved symbols). This means that
multiarch has zero benefit there - you can only have one instance of the
daemon installed anyway, and the plugin-support library or plugins for
other architectures are of no use :-)
If multiarch actually benefits this particular package (I know nothing
about lcmaps) then read on...
> It's harder to reversely state that the new framework conflicts with
> older plugin packages: they would all have to be listed in the control
> file, and then only the known ones could be listed (it's not
> inconceivable other parties made their own outside of Debian).
As a transitional measure, you could patch lcmaps so it searches
/usr/lib/lcmaps with lower priority than ${libdir}/lcmaps, so that these
older plugin packages continue to work for a couple of years. That's the
solution that was used for things like PAM and Pango.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54e4837d.8030...@debian.org
