[ 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 <[email protected]>: > > 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
