2014-03-18 16:07 GMT+01:00 Michael Biebl :
>
> Assuming the interface and data provided by qmi-proxy is aritecture
> independent, my proposal would be:
>
> - Install qmi-proxy into a non-ma path, e.g. /usr/lib/libqmi/qmi-proxy
> so all library versions can find it (the library seems to use g_spawn
2014-03-27 16:03 GMT+01:00 Michael Biebl :
> Am 18.03.2014 16:37, schrieb Marius Kotsbak:
> > 2014-03-18 16:07 GMT+01:00 Michael Biebl :
> > I will have a look at your proposed solution then. What we miss then is a
> > user that know about the limitations and want to have two different
> > version
Am 18.03.2014 16:37, schrieb Marius Kotsbak:
> 2014-03-18 16:07 GMT+01:00 Michael Biebl :
> I will have a look at your proposed solution then. What we miss then is a
> user that know about the limitations and want to have two different
> versions installed but not used at the same time (as the bina
On Tue, Mar 18, 2014 at 04:07:46PM +0100, Michael Biebl wrote:
> Steve, I took the liberty to CC since you have a good grasp on the M-A
> stuff. Please have a look at [0]. Your input would be most welcome.
> Please let me know if the suggestions above make sense, are complete
> non-sense or if ther
2014-03-18 16:07 GMT+01:00 Michael Biebl :
> Am 18.03.2014 15:24, schrieb Marius Kotsbak:
> > Yes, that is what I got. I would if I was sure that this is not a
> packaging
> > issue (as the qmi-proxy is a multi-arch binary).
>
>
> So, I had a quick look at [0]. Putting qmi-proxy in the library pac
Am 18.03.2014 15:24, schrieb Marius Kotsbak:
> Yes, that is what I got. I would if I was sure that this is not a packaging
> issue (as the qmi-proxy is a multi-arch binary).
So, I had a quick look at [0]. Putting qmi-proxy in the library package
seems wrong and wasteful to me, since apparently yo
6 matches
Mail list logo
