[Laszlo Boszormenyi]
Also it would fetch more dependencies (GnuTLS related just for neon)
and I don't know if Subversion serving over https would interfere
with Apache2 or not. Reason: Apache2 is linked with OpenSSL,
Subversion and neon will be linked with GnuTLS.
Don't worry about that: the
If you decide to support gnutls only, that would be 'libneon26', right?
So no binNMU needed, but a source upload would be needed for bazaar.
And tla, and presumably cadaver if anyone wants to go solve that license
problem.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of
Laszlo Boszormenyi wrote:
No, this is a very bad idea. No application linking against libneon should
*care* whether it's linked with gnutls or not; you should *not* expose this
in the library name.
You are right, that's why I made them conflict with each other, as both
provide the same
Laszlo Boszormenyi wrote:
On Sun, 2006-12-03 at 20:25 -0800, Steve Langasek wrote:
This ensures that any package that should avoid being linked against OpenSSL
for license reasons will get the gnutls flavor of the library, but other
packages can link against either flavor.
OK, I have to
On Mon, Dec 04, 2006 at 07:38:13AM +0100, Laszlo Boszormenyi wrote:
Based on my understanding of the license requirements and the compatibility
of the two libs, I would suggest one of two solutions:
- make libneon26-gnutls Provide: libneon26, and keep the current shlibs
as-is
- change
On Mon, 2006-12-04 at 20:24 -0800, Steve Langasek wrote:
On Mon, Dec 04, 2006 at 07:38:13AM +0100, Laszlo Boszormenyi wrote:
This ensures that any package that should avoid being linked against
OpenSSL
for license reasons will get the gnutls flavor of the library, but other
packages
Hi all involved,
On Sun, 2006-12-03 at 01:03 -0600, Peter Samuelson wrote:
Sorry for the dupe, Adam beat me to this one.
No problem. To tell the truth, I knew something is coming.
See #401398 for my
proposed solution, which is basically to put the following in both
shlibs files:
libneon
On Sun, Dec 03, 2006 at 10:57:03AM +0100, Laszlo Boszormenyi wrote:
Hi all involved,
On Sun, 2006-12-03 at 01:03 -0600, Peter Samuelson wrote:
Sorry for the dupe, Adam beat me to this one.
No problem. To tell the truth, I knew something is coming.
See #401398 for my
proposed solution,
Steve Langasek wrote:
What's the release team point Vorlon?
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.
Great point! Package libneon26 can contain BOTH versions of the library.
Then the app dynamically
[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
On Sun, 2006-12-03 at 20:25 -0800, Steve Langasek wrote:
On Sun, Dec 03, 2006 at 10:57:03AM +0100, Laszlo Boszormenyi wrote:
On Sun, 2006-12-03 at 01:03 -0600, Peter Samuelson wrote:
Having a GPL package depend on a GPL-incompatible (via OpenSSL) libneon26
package by default would still be
forcemerge 401388 401398
thanks
Sorry for the dupe, Adam beat me to this one. See #401398 for my
proposed solution, which is basically to put the following in both
shlibs files:
libneon 26 libneon26 | libneon26-gnutls
Peter
signature.asc
Description: Digital signature
12 matches
Mail list logo
