Path: csiph.com!news.mixmin.net!news.unit0.net!newsfeed.CARNet.hr!news.spin.it!bofh.it!news.nic.it!robomod From: Simon McVittie Newsgroups: linux.debian.bugs.dist,linux.debian.maint.python Subject: Bug#883246: ITP: python-enum-compat -- Python enum/enum34 compatibility package Date: Fri, 01 Dec 2017 12:50:01 +0100 Message-ID: References: X-Mailbox-Line: From debian-bugs-dist-request@lists.debian.org Fri Dec 1 11:45:08 2017 Old-Return-Path: X-Spam-Flag: NO X-Spam-Score: -4.21 Reply-To: Simon McVittie , 883246@bugs.debian.org Resent-To: debian-bugs-dist@lists.debian.org Resent-Cc: wnpp@debian.org, =?utf-8?b?T25kxZllaiBOb3bDvQ==?= X-Debian-Pr-Message: followup 883246 X-Debian-Pr-Package: wnpp X-Spam-Bayes: score:0.0000 Tokens: new, 11; hammy, 150; neutral, 65; spammy, 0. spammytokens: hammytokens:0.000-+--sk:python3, 0.000-+--dpkgsource, 0.000-+--dpkg-source, 0.000-+--upstreams, 0.000-+--H*F:U*smcv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Debian-Message: from BTS X-Mailing-List: archive/latest/1422899 List-ID: List-URL: Approved: robomod@news.nic.it Lines: 30 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Cc: 883246@bugs.debian.org, debian-python X-Original-Date: Fri, 1 Dec 2017 11:42:10 +0000 X-Original-Message-ID: <20171201114210.GA4195@perpetual.pseudorandom.co.uk> X-Original-References: <151212171747.8735.3910383764092601931.reportbug@sid> <20171201102522.GA30779@perpetual.pseudorandom.co.uk> <151212171747.8735.3910383764092601931.reportbug@sid> Xref: csiph.com linux.debian.bugs.dist:866310 linux.debian.maint.python:9988 On Fri, 01 Dec 2017 at 12:13:26 +0100, Ondrej Novy wrote: > 2017-12-01 11:25 GMT+01:00 Simon McVittie <[1]smcv@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