[Steve Langasek] > - make libneon26-gnutls Provide: libneon26, and keep the current shlibs > as-is
Would need versioned Provides, given the current shlibs file. (Although the versioning in the file may not be necessary, as the ABI doesn't seem to have changed since the first Debian release of neon26.) > - change the shlibs of libneon26 to libneon 26 libneon26 | libneon26-gnutls, > but leave the shlibs of libneon26-gnutls as-is Nod. > It also assumes that there's really a reason for separate gnutls and > OpenSSL flavors of the package. I'm not sure what that reason is. I'm guessing it was pre-etch risk aversion. Who knows how well tested the gnutls-using code is - it is, after all, not upstream's default. It _appears_ to work fine with subversion but I only tested lightly. [Adam Majer] > Great point! Package libneon26 can contain BOTH versions of the > library. Then the app dynamically links with a given library. This > fixes ALL problems. All problems except pulling in too many dependencies. Also, conceptually I don't know that I care for the idea that the two libraries have _exactly_ the same ABI yet export different SONAMEs. The "alternatives" shlibs file idea avoids this.
signature.asc
Description: Digital signature
