[PATCH] debian: strictly depend on the same version of libnotmuch

[PATCH] debian: strictly depend on the same version of libnotmuch

[Uwe Kleine-König]

It took quite some time to debug why folder: searches didn't work for me
though I had notmuch 0.6~rc1 installed. amdragon in #notmuch found out
that I still had libnotmuch1 0.5+nmu3 installed.

To prevent the same problem in the future let notmuch depend on the same
version of libnotmuch1.

Signed-off-by: Uwe Kleine-König <ukleinek@strlen.de>
---
 debian/control |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/debian/control b/debian/control
index 78c9849..03afdf4 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Dm-Upload-Allowed: yes
 
 Package: notmuch
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: libnotmuch1 (= ${binary:Version}), ${shlibs:Depends}, ${misc:Depends}
 Recommends: notmuch-emacs | notmuch-vim
 Description: thread-based email index, search and tagging
  Notmuch is a system for indexing, searching, reading, and tagging
-- 
1.7.5.4

Re: [PATCH] debian: strictly depend on the same version of libnotmuch

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 692 bytes --]

On Sat,  9 Jul 2011 21:17:09 +0200, Uwe Kleine-König <ukleinek@strlen.de> wrote:

> To prevent the same problem in the future let notmuch depend on the same
> version of libnotmuch1.
> 

I added the additional comment 

,----
|  The underlying issue is that the libnotmuch interface is not
|  entirely captured by the set of exported symbols. In particular the
|  query syntax can change without being visible to the linker at all.
`----

and pushed to the release branch, where I'm building up bugfix version
(tentatively numbered 0.6.1) for upload to Debian early next week, after
0.6 migrates to testing.  So far this new version has only Debian
packaging changes.

d

[-- Attachment #2: Type: application/pgp-signature, Size: 315 bytes --]

Re: [PATCH] debian: strictly depend on the same version of libnotmuch

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

On 07/10/2011 08:53 AM, David Bremner wrote:
> |  The underlying issue is that the libnotmuch interface is not
> |  entirely captured by the set of exported symbols. In particular the
> |  query syntax can change without being visible to the linker at all.

This suggests to me that we may need to be bumping the SONAME when the
query string format changes, no?

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1030 bytes --]

Re: [PATCH] debian: strictly depend on the same version of libnotmuch

[David Bremner]

On Sun, 10 Jul 2011 17:12:19 -0400, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
> On 07/10/2011 08:53 AM, David Bremner wrote:
> > |  The underlying issue is that the libnotmuch interface is not
> > |  entirely captured by the set of exported symbols. In particular the
> > |  query syntax can change without being visible to the linker at all.
> 
> This suggests to me that we may need to be bumping the SONAME when the
> query string format changes, no?
> 

If we follow the same rules as with symbols, then only when it breaks
backwards compatability.

d

Re: [PATCH] debian: strictly depend on the same version of libnotmuch

[Daniel Kahn Gillmor]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

On 07/10/2011 10:36 PM, David Bremner wrote:
>> This suggests to me that we may need to be bumping the SONAME when the
>> query string format changes, no?
> 
> If we follow the same rules as with symbols, then only when it breaks
> backwards compatability.

Right, but what breaks backwards compatibility in a string-based indexer?

If the query "foo bar:baz" is interpreted as a search for two separate
simple strings, and then an update treats the "bar:" suffix specially,
is that backwards-incompatible because the semantics of the identical
search change?

The only way i can currently imagine "backwards compatibility" is if
version X has a set of query strings which all return some kind of "not
implemented" error value, and then version X+1 returns a legitimate
response for some subset of those same query strings.

Otherwise, each change in query string syntax actively modifies (in a
non-backwards-compatible way) the semantics of some part of the interface.

Is there some other way to view this distinction?

	--dkg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 1030 bytes --]