Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: gregor herrmann <gregoa <at> debian.org>
Subject: Bug#692979: Bug#693002: libimager-perl: breaks libimager-qrcode-perl
Newsgroups: gmane.linux.debian.devel.bugs.rc
Date: Monday 12th November 2012 17:26:32 UTC (over 3 years ago)
On Sun, 11 Nov 2012 18:31:54 -0500, Michael Gilbert wrote:

Hi,

thanks for pointing out that we have a problem with the changing API
in Imager which we have missed so far :/

> Hi, the ABI bump in version 0.85 breaks at least libimager-qrcode-perl
> and perhaps other packages.

Looking at #692979 which has
| "Imager API version incorrect loaded 5 vs expected 3"
I doubt this was about 0.85:

Looking a bit closer:
IMAGER_API_VERSION is defined in imexttypes.h, and looking through
the git history we have:

0.85:

-#define IMAGER_API_VERSION 1
+#define IMAGER_API_VERSION 2

0.86:

-#define IMAGER_API_VERSION 2
+#define IMAGER_API_VERSION 3

0.88:

-#define IMAGER_API_VERSION 3
+#define IMAGER_API_VERSION 4

0.90:

-#define IMAGER_API_VERSION 4
+#define IMAGER_API_VERSION 5

Looks like libimager-qrcode-perl was compiled against 0.86 or 0.87
(probably 0.87, looking that the upload dates) and is not happy about
any Imager version >= 0.88.

And I'm also not sure that your NMU for libimager-qrcode-perl is
correct; if I understand this correctly, it doesn't need any specific
version of Imager, but just the same at buildtime and runtime, so a
simple binNMU should be enough to fix the current bug. - Of course
that's not a long term solution.
 
> This can be fixed with a breaks libimager-qrcode-perl <=
> libimager-qrcode-perl_0.033-1.

Not really ... I mean maybe immediately yes, but libimager-perl can't
really track against which of its versions libimager-qrcode-perl is
built.

So yes, we have a problem here regarding API changes which we didn't
see so far, and this brings us to #693003:


On Sun, 11 Nov 2012 18:35:07 -0500, Michael Gilbert wrote:

> Please consider including the API version in the binary package file
> name.  This will prevent issues like #692979 and 693002 in the future.

Including the API version in the package file name feels clumsy; what
we might try to do is to setup a machinery like we have in
libdbi-perl, which:

- Provides: perl-dbdabi-${perl-dbdabi-version}
- ships a debhelper sequence and helpers, and a makefile snippet for
  including in debian/rules
- which arch:any packages build-depending on DBI can then use [0],
  and adds perl-dbdabi-${perl-dbdabi-version} to their Depends
- which allows simple binNMUs whenever
  perl-dbdabi-${perl-dbdabi-version} changes


On the other hand, at least for now, libimager-qrcode-perl is the only
consumer of libimager-perl ... (The other reverse dependency,
libmojomojo-perl, is arch:all and just uses Imager in its test).


Comments from other pkg-perl members welcome.


Thanks again for bringing this to our attention!


Cheers,
gregor


[0]
cf.
http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libdbi-perl.git;a=blob;f=debian/README.Debian;hb=HEAD
 

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ -
OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer  -  http://www.debian.org/
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation
Europe
   `-   NP: The Mamas & The Papas: Words Of Love
 
CD: 16ms