Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?

Niko Tyni ntyni at debian.org
Thu Feb 28 16:01:01 GMT 2019


On Thu, Feb 28, 2019 at 12:06:18PM +0000, Dmitry Bogatov wrote:
> 
> [2019-02-27 21:20] Niko Tyni <ntyni at debian.org>
> > > - update perl to build-depend on libgdbm-dev (>= 1.18-2) and Break
> > >   older versions of libmarc-charset-perl (and any other perl packages
> > >   bundling GDBM or NDBM databases)
> > > 
> > > - update libmarc-charset-perl (and any other perl packages bundling
> > >   GDBM or NDBM databases) to build-depend and depend on the newer perl
> > > 
> > > I assume other language bindings like python-gdbm will need something
> > > similar.
> >
> > But ideally gdbm would restore compatibility and libmarc-charset-perl would
> > not need any changes.
> 
> I believe upstream release 1.8.1 introduced change, that
> made it possible to read old /usr/lib/libmarc-charset-perl/Table. Am I
> missing something in current situation?

I thought so too, but this new bug highlights the fact that the fix
does not work on all architectures.  This was missed earlier because
Debian does not have autopkgtest checks on !amd64, so we're relying
on user bug reports and haven't got any so far.

I've now verified that creating GDBM files with Perl, Python 2 or Python 3
on stretch i386 and then upgrading to buster renders the old databases
unusable with the corresponding software in buster.

I can file a separate bug against src:gdbm if that makes things clearer.

> By the way, I disagree about compability. If all we need to make
> everything good is just a binNMU, I'd rather not introduce any
> patches/hacks/compatibility layers/etc.

binNMU'ing libmarc-charset-perl will only fix libmarc-charset-perl,
not unpackaged local user databases. If those become unusable on
stretch -> buster upgrades with no way to recover them, that seems
like a major problem. 

binNMU'ing libmarc-charset-perl does not fix partial upgrades where
perl that uses a newer libgdbm is upgraded before  libmarc-charset-perl.
Hence the need for Breaks and versioned build dependencies that I listed.

> By the way, it is sad that libmarc-charset-perl uses gdbm, not cdb.

Are you referring to https://cr.yp.to/cdb.html ? I see there's a CDB_File
Perl module in libcdb-file-perl but I'm not familiar with it. Seems worth
a wishlist bug.
-- 
Niko Tyni   ntyni at debian.org



More information about the pkg-perl-maintainers mailing list