On Fri, 01 Dec 2017 at 12:13:26 +0100, Ondrej Novy wrote:
> 2017-12-01 11:25 GMT+01:00 Simon McVittie <[1]s...@debian.org>:
> Within Debian, wouldn't this be better achieved by having Python 2
> packages
> that require enum34 depend on python-enum34 directly, as they already do?
>
> I already tried this solution.
That's unfortunate - the solution you tried first does seem better.
Would it perhaps work to bundle enum_compat's egg-info with
python-enum34? It doesn't seem great to be introducing a whole new
source package just to express a conditional dependency (that will itself
become obsolete when Python 2 does), and it's not as if enum_compat has
any actual code, so hopefully it will never have bugs or new versions.
dpkg-source and gbp can do multi-tarball upstreams these days (yquake2
is one example).
That doesn't work either if a Python 3 package depends on enum_compat,
but it would seem a little absurd to have a python3-enum-compat package,
given that we no longer support any version of Python 3 that doesn't
have enum. (And in the worst case, python3-dev could provide egg-info
for enum_compat, if dependencies on it become widespread.)
I can't help wondering whether it would be a better solution for
upstreams that need enum to depend on
(['enum34'] if sys.version < (3, 4) else []), or on Python 3.4
(either way, short-term it's still a Debian patch, but long-term it's
hopefully upstreamable).
smcv
