On Sun, Dec 20, 2015 at 01:29:10PM -0500, Ben Rosser wrote:
What's the right thing to do here? Replace pdfminer? Ship python3-pdfminer-six,
have it provide python3-pdfminer, and keep using the original package for
Python 2? Do nothing, and wait and see what happens upstream?
It's a tough thing to decide as there's many unanswerable questions --
will
the pdfminer upstream change their mind about having dual py2 and py3
compat? Will pdfminer.six development tail off and die? You can't predict
the future so anything has some risk of backing the wrong horse.
Luckily, if circumstances change with the upstreams we can always change our
minds about what the right thing to do is. If you are worried about that,
I think implementing a plan that makes it as easy as possible to change
which fork we're packaging and promoting later is optimal. So keeping the
python-pdfminer package name but packaging the source for pdfminer-six seems
to make sense to me. That way, as long as they stay API compatible,
packagers of dependent packages don't have to do anything if you have to
switch from one upstream fork to another.
-Toshio