Re: Your recent sqlite3 and neon27 uploads
Hi,
On Fri, 2010-12-17 at 10:31 +0100, Laszlo Boszormenyi wrote:
> On Thu, 2010-12-16 at 19:21 +0000, Adam D. Barratt wrote:
> > On Mon, 2010-12-13 at 22:48 +0100, Laszlo Boszormenyi wrote:
> [ about neon27 packages ]
[...]
> There are changes for win32 and Solaris; the changelog says:
> Fix possible Solaris linker errors if building static library
> Win32: Fix Kerberos authentication support with SSPI (Danil Shopyrin)
> Further fix for SSPI support on Win32 (Danil Shopyrin)
>
> Also fixes the following:
> Fix error handling when pulling a request body from an file (thanks to
> Lou Montulli)
> Fix ne_request_dispatch() return value for SOCKS proxy failure cases
> Tighten SSL cert ID checks to deny a wildcard match against an IP
> address
>
> The latter can be important, but I agree that other OSes fixes are not.
The wildcard ID check was one I debated; I'm not entirely sure whether
the bug being fixed is common or severe enough to justify the behaviour
change at this point.
> > The bigger issue is that because neon27 calls dh_makeshlibs with -V, the
> > shlibs are bumped with every upload even if it's not necessary.
> Will remove that switch.
The package descriptions of libneon27{,-gnutls} say "WARNING: THE NEON
API IS NOT YET STABLE" so removing the versioning entirely might not be
a good idea; on the basis that there don't appear to have been any
obvious API changes since the version currently in squeeze, how about
something like:
+shlibs-version=0.29.3-3
[...]
- dh_makeshlibs -V
+ dh_makeshlibs -p$(package) -V'$(package) (>= $(shlibs-version))'
+ dh_makeshlibs -p$(package)-gnutls -V'$(package)-gnutls (>= $(shlibs-version))'
> > Looking forward to hearing your thoughts on where we go from here.
> We've two routes. For the first and very last time, you let neon27 to
> go into Squeeze
Earlier in the process, I'd probably have favoured this option; at this
stage I'd prefer to avoid the extraneous changes.
> and I won't upload anything during freeze without asking
> and confirmation now and ever.
That might be going a little far. :-)
> Second, I upload a new neon27 package, with patches that back out all
> unrelated changes. In short, I make a v0.29.3 + previously backported
> changes from the v0.29.5 tree.
This sounds a little overly complicated and will make the diff harder to
review. The "usual" approach is to re-upload the earlier upstream
source using a version number such 0.29.5really0.29.3, making the binary
0.29.5really0.29.3-1.
> If I should go this route, may I name it 0.29.5-1really0.29.3 ?
See above.
Regards,
Adam
Reply to: