Re: moving to multiarch for packages with plugins

2015-02-19 Thread Dennis van Dok
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.

Re: moving to multiarch for packages with plugins

2015-02-18 Thread Rebecca N. Palmer
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

Re: moving to multiarch for packages with plugins

2015-02-18 Thread Simon Richter
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

Re: moving to multiarch for packages with plugins

2015-02-18 Thread Simon McVittie
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

Re: moving to multiarch for packages with plugins

2015-02-18 Thread Neil Williams
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