Hi, On Mon, Feb 10, 2014 at 11:36:46PM +0100, Marius B. Kotsbak wrote: > On 07. feb. 2014 08:14, Guido Günther wrote: > > blocks 737572 731851 > > thanks > > > > Hi, > > On Tue, Feb 04, 2014 at 10:21:43AM +0100, Marius Kotsbak wrote: > >> Hi > >> > >> It is actually almost ready in the git repo I have pushed. > >> > >> The remaining thing is to find out how to handle the qmi-proxy binary, > >> which is used by the lib. > > > > The binary is libexecdir so it ends up in /usr/lib/<arch> on Debian, > > so which not just ship it in the libqmi-glib itself? It useless without > > the lib anyway. > dh > Yes, that was my plan, but the problem is when libqmi-glib2 is released, > the path will be the same, so in that case, it should be placed in the > recommended path including the package name (/usr/share/...?). Anyway,
Use share is for architecture _independent_ data. > as only one qmi-proxy can be run at the same time to work, I'm proposing > the following: I still don't understand why you can't leave it in /usr/lib/<arcH>? That's even what dh passes as libexecdir. Cheers, -- Guido > > * Put qmi-proxy in a new package libqmi-glib1-qmiproxy. Let it > provide/conflict with "qmi-proxy" virtual package, to ensure only one is > installed (for one architecture or ABI major version). Let it require > libqmi-glib1, and let libqmi-glib1 recommend libqmi-glib1-qmiproxy. > > * Modemmanager package (and other packages actually using the proxy > flag) is set to depend on libqmi-glib1-qmiproxy too. > > -- > Marius > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org