Versioning depends or shared-lib style for a perl module

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

I have a package (dgit) which generates two binary packages (dgit and
dgit-infastructure) both of which need a shared Dgit.pm Perl module.

It's a native package.  I'm not sure if I want to promise that the
Perl module has a very stable API.  I appear to have accidentally
destabilised the API in my work-in-progress branch.

I want to be able to install dgit (1.4) and dgit-infrastructure
(2.0~~) at the same time so that I can use adt-run to test whether my
update is properly compatible at the protocol level.  Currently this
doesn't work well because the perl module Debian::Dgit is not
suitably compatible.

Clearly I have done this wrong :-).  I'd like some advice about which
is the "right" direction.

My options seem to be:

1. Make the module (which is essentially internal to these packages -
   it's not intended to be a public interface) have a
   forward-compatible API and split it off into its own .deb.

2. Arrange to ship a separate copy of Debian/Dgit.pm (and a small
   ancillary module) in a separate path in dgit-infrastructure.deb and
   modify PERLLIB in the scripts in that .deb to use it.  The total
   duplicated code would be 10kby or so.

3. Make the module into a separate .deb and explicitly version it,
   soname-style.  Use some at-install-time seddery to change in-tree
   references `use Debian::Dgit;' to `use Debian::Dgit_2.0' or some
   such, and generate appropriate Depends.  (This would ideally need
   tooling support which doesn't currently exist.)

Currently I'm leaning towards option 2.  Opinions and other
suggestions very welcome.

Thanks,
Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.