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

Reply via email to