libpcsclite1 is not compatible with multiarch

[Scott Sweeny]

I recently ran into an issue trying to install a 32-bit package which depends on libpcsclite1. That package drew in the i386 package for libpcsclite1, which conflicted with and subsequently uninstalled the 64-bit version, which in turn uninstalled wpasupplicant and network-manager (this only really happened because I failed to pay close enough attention to the consequences of installing the package).

If possible, this package should be made multiarch compatible.

ssweeny@talyn:~$ sudo apt-get install libpcsclite1:i386
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  pcscd:i386
The following packages will be REMOVED:
  libpcsclite1 network-manager network-manager-gnome wpasupplicant
The following NEW packages will be installed:
  libpcsclite1:i386
0 upgraded, 1 newly installed, 4 to remove and 0 not upgraded.
Need to get 0 B/24.0 kB of archives.
After this operation, 4,588 kB disk space will be freed.
Do you want to continue [Y/n]?

[Ludovic Rousseau (ludovic-rousseau-gmail)]

I agree to support multi-arch.

If someone can provide a patch I will integrate it in the Debian version of pcsc-lite. Or I will have to write the patch myself but it may take some time.

[Rick Spencer (rick-rickspencer3)]

assigning to foundations to have a look at multi-arch compatibility

[Ludovic Rousseau (ludovic-rousseau-gmail)]

I am working on multi-arch for the Debian package righ now.
Expect a new Debian upload "soon".

[Ludovic Rousseau (ludovic-rousseau+ubuntu-one)]

The bug is fixed in pcsc-lite version 1.8.3-1 I just uploaded in Debian unstable.

[Launchpad Janitor (janitor)]

This bug was fixed in the package pcsc-lite - 1.7.4-2ubuntu2

---------------
pcsc-lite (1.7.4-2ubuntu2) precise; urgency=low

  * Install into multiarch locations. LP: #949912.
 -- Matthias Klose <email address hidden> Wed, 04 Apr 2012 10:00:42 +0200

[Martin-Éric Racine (q-funk)]

This release actually BREAKS operation. Reverting to 1.7.4-2ubuntu1 restored normal operation.

[Matthias Klose (doko)]

On 10.04.2012 17:47, Martin-Éric Racine wrote:
> This release actually BREAKS operation. Reverting to 1.7.4-2ubuntu1
> restored normal operation.

as always, thanks for the very descriptive report. please could you elaborate
what exactly is broken?

[Steve Langasek (vorlon)]

Martin-Éric, that's not an actionable bug report. Please file a new bug and tell us /what/ breaks.

[Martin-Éric Racine (q-funk)]

Please see bug #978974

[Reinhard Tartler (siretart)]

The change for this task is not complete yet. The libpcsclite-dev_1.7.4-2ubuntu2_amd64.deb installs a .la file with these contents:

[...]
# Directory that this library needs to be installed in:
libdir='/usr/lib'

That directory is wrong. Either it should read correctly, ot this file should be removed.

[Reinhard Tartler (siretart)]

Also, I think the .pc file is wrong:

>> grep '/lib' /usr/lib/x86_64-linux-gnu/pkgconfig/libpcsclite.pc
prefix=/usr
libdir=${exec_prefix}/lib
usbdropdir=/usr/lib/pcsc/drivers

Obviously, libdir need to be adjusted.

Moreover, I think the usbdropdir should be moved in order to allow pcsc drivers for different architectures to be installed.

[Steve Langasek (vorlon)]

On Fri, Apr 13, 2012 at 07:26:00AM -0000, Reinhard Tartler wrote:
> The change for this task is not complete yet. The libpcsclite-
> dev_1.7.4-2ubuntu2_amd64.deb installs a .la file with these contents:

> [...]
> # Directory that this library needs to be installed in:
> libdir='/usr/lib'

> That directory is wrong. Either it should read correctly, ot this file
> should be removed.

What, practically speaking, is the impact of this field being wrong here?
I don't think it's correct to say that libpcsclite1 is still "not compatible
with multiarch". Shouldn't this be tracked as a new bug?

On Fri, Apr 13, 2012 at 03:21:54PM -0000, Reinhard Tartler wrote:
> Also, I think the .pc file is wrong:

> >> grep '/lib' /usr/lib/x86_64-linux-gnu/pkgconfig/libpcsclite.pc
> prefix=/usr
> libdir=${exec_prefix}/lib
> usbdropdir=/usr/lib/pcsc/drivers

> Obviously, libdir need to be adjusted.

> Moreover, I think the usbdropdir should be moved in order to allow pcsc
> drivers for different architectures to be installed.

It probably should, yes, but that's a secondary issue. So far no one has
been asking for multiarch usability of libpcsclite1, only installability.

[Ludovic Rousseau (ludovic-rousseau+ubuntu-one)]

Debian has version 1.8.3-2 of pcsc-lite and do not have these problems.

$ grep lib /usr/lib/i386-linux-gnu/pkgconfig/libpcsclite.pc
libdir=${prefix}/lib/i386-linux-gnu
usbdropdir=/usr/lib/pcsc/drivers
Libs: -L${libdir} -lpcsclite

libpcsclite-dev do not provide any .la file

Maybe Ubuntu could upgrade pcsc-lite to the latest version.

Also, do not touch to usbdropdir unless you know EXACTLY what you are doing. And I guess you don't.
You can't install drivers for different architecture. You don't need that (unless you use a proprietary driver only available for 1 architecture). Also note that only one pcscd can be used at the same time.

[Steve Langasek (vorlon)]

Still considering this fixed, then. Will pick up the new package version from Debian for 12.10.

[Reinhard Tartler (siretart)]

On Fri, Apr 13, 2012 at 18:28:48 (CEST), Steve Langasek wrote:

> On Fri, Apr 13, 2012 at 07:26:00AM -0000, Reinhard Tartler wrote:
>> The change for this task is not complete yet. The libpcsclite-
>> dev_1.7.4-2ubuntu2_amd64.deb installs a .la file with these contents:
>
>> [...]
>> # Directory that this library needs to be installed in:
>> libdir='/usr/lib'
>
>> That directory is wrong. Either it should read correctly, ot this file
>> should be removed.
>
> What, practically speaking, is the impact of this field being wrong here?
> I don't think it's correct to say that libpcsclite1 is still "not compatible
> with multiarch". Shouldn't this be tracked as a new bug?

I noticed that a driver, which uses libtool to link against libpcsclite,
"suddently" gained an rpath to a very weird path. Libtool uttered a
"warning: library libpcsclite.la was moved" and decided to add the
rpath. removing the .la solved the issue.

> On Fri, Apr 13, 2012 at 03:21:54PM -0000, Reinhard Tartler wrote:
>> Also, I think the .pc file is wrong:
>
>> >> grep '/lib' /usr/lib/x86_64-linux-gnu/pkgconfig/libpcsclite.pc
>> prefix=/usr
>> libdir=${exec_prefix}/lib
>> usbdropdir=/usr/lib/pcsc/drivers
>
>> Obviously, libdir need to be adjusted.
>
>> Moreover, I think the usbdropdir should be moved in order to allow pcsc
>> drivers for different architectures to be installed.
>
> It probably should, yes, but that's a secondary issue. So far no one has
> been asking for multiarch usability of libpcsclite1, only
> installability.

As Ludovic indicates, we should not modify usbdropdir. However, the
issue with libdir still stands, and I still do believe that this is in
scope of this particular bug.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Reinhard Tartler (siretart)]

On Fri, Apr 13, 2012 at 18:38:00 (CEST), Ludovic Rousseau wrote:

> Debian has version 1.8.3-2 of pcsc-lite and do not have these problems.
>
> $ grep lib /usr/lib/i386-linux-gnu/pkgconfig/libpcsclite.pc
> libdir=${prefix}/lib/i386-linux-gnu
> usbdropdir=/usr/lib/pcsc/drivers
> Libs: -L${libdir} -lpcsclite
>
> libpcsclite-dev do not provide any .la file
>
> Maybe Ubuntu could upgrade pcsc-lite to the latest version.
>
> Also, do not touch to usbdropdir unless you know EXACTLY what you are doing. And I guess you don't.
> You can't install drivers for different architecture. You don't need
> that (unless you use a proprietary driver only available for 1
> architecture). Also note that only one pcscd can be used at the same
> time.

OK, I will not touch this.

Still, imagine that I have an proprietary application that is only
available as _i386.deb and links against libpcsc-lite. So with
multi-arch, I can install it and it will use the i386 version of
pcsc-lite. However, that proprietary application will not be able to use
the amd64 versions of my free driver that is installed in
/usr/lib/pcsc/drivers.

AFAIUI, the proper solution here would be to make pcscd search in
/usr/lib/pcsc/drivers/$(DEB_HOST_MULTIARCH).

Do I miss something here?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[Ludovic Rousseau (ludovic-rousseau+ubuntu-one)]

the same pcscd can be used by two libpcsclite in 32 and 64 bits at the same time.
So if your application is 32-bits only you can still use it on a 64-bits system with a 64-bits pcscd and 64-bits driver.

See http://old.nabble.com/new-version-available:-pcsc-lite-1.4.99-td14711674.html

[Reinhard Tartler (siretart)]

(I'm replying in private to avoid further clutter in the buglog)

On Fri, Apr 13, 2012 at 20:36:48 (CEST), Ludovic Rousseau wrote:

> the same pcscd can be used by two libpcsclite in 32 and 64 bits at the same time.
> So if your application is 32-bits only you can still use it on a 64-bits system with a 64-bits pcscd and 64-bits driver.
>
> See
> http://old.nabble.com/new-version-available:-pcsc-lite-1.4.99-td14711674.html

Ah, now it makes sense to me. So the pcsc-driver is never loaded into
the application's address space, but uses libpcsclite.so to talk to the
daemon, which acts as a proxy to the actual driver.

Thanks for pointing me to that post.

Cheers,
Reinhard
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4