[pkg-wpa-devel] Bug#612842: Please make dependendency on libpcsclite1 optional

[Guillem Jover]

[ Resending (and trimmed recipients), as it seems the first time it
  didn't go through, mostly for completeness, and for reference
  purposes. ]

Hi!

On Sun, 2011-02-13 at 09:25:58 +0100, Ludovic Rousseau wrote:
> 2011/2/13 Michael Biebl <biebl at debian.org>:
> > On 11.02.2011 21:43, Ludovic Rousseau wrote:
> > > reassign 612842 wpasupplicant
> > > thank
> > >
> > > The problem is with wpasupplicant, not with libpcsclite1.
> > > libpcsclite1 is not usefull without pcscd (and its dependencies).
> > > I also plan to use libudev instead of libhal in pcscd. But it is
> > > not yet ready.
> > >
> > > The wpasupplicant maintainer(s) just decided to remove the smart
> > > card support (see Debian bug #612715). So this bug, reassigned to
> > > wpasupplicant, will be solved soon.

Regardless of wpasupplicant fixing this by dropping the dependency, I
disagree this is not a problem with libpcsclite. While for libpcsclite
pcscd might be required, it might not for the programs using it, or for
users w/o a smart card, and forcing a Depends seems too much, when a
Recommends would work for everyone. It would get installed by default,
and users could have the option to opt-out and remove it if desired.

Also consider that this might fix this particular instance, but what
about other programs willing to use libpcsclite? Or suddenly no one
can make use of it because of the possible dependencies?

> > Hm, I don't see how libpcsclite1 depending on pcscd is a bug in wpasupplicant.
> > Could you elaborate?
> 
> wpasupplicant depends on libpcsclite1 to add support of smart cards.
> libpcsclite1 has dependencies on other packages, in particular
> indirectly on libhal.
> 
> Adding smart card support has a (high) cost for every body, including
> the vast majority of wpasupplicant users with no smart card.

Only if it's a Depends!

> The best solution is for spasupplicant to use the libpcsclite1 library
> only when needed/requested by the user.
> Use dlopen() instead of a direct link, and change the Depends: to a
> Suggests: instead.
> 
> I proposed a patch [1] in Debian bug #531592

Using dlopen() for shared objects not being part of ones project is
just broken, please don't do or advocate that. It will cause numerous
pains on transitions as the packages cannot (usually) just be binNMUed
for it to pickup the new SONAME, and even if it can and any weak package
metadata gets also updated, users will not have a clue what they are
missing if it stops working, as it breaks partial upgrades and similar.

So I'd kindly ask that this gets switched as to a Recommends, regardless
of any future switch to libudev (I don't really want the daemon even if
it's not using hal and friends).

thanks,
guillem