Wow -- thanks so much everyone who replied. This is really helpful!
Cheers,
Dennis van Dok (on behalf of the other developers)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.
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.
openscenegraph does that (currently openscenegraph-plugin-citygml-shared
and libopenscenegraph's
Hi,
Am 18.02.2015 um 11:49 schrieb Dennis van Dok:
> 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 thei
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
On Wed, 18 Feb 2015 11:49:50 +0100
Dennis van Dok wrote:
> Hi,
>
> 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-g
Hi,
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.
This is not a big deal except that t
6 matches
Mail list logo