On Tue, 5 Feb 2019 at 19:53, Antoine Beaupré <anar...@orangeseeds.org> wrote: > I guess I could just drop the "python" dependency from there completely > and rely on the bzr bits to do the right thing if they are setup.
Yes, in principle you could write out git | (bzr, python) as git | bzr, git | python but this feels pointless since bzr already depends on python. Dropping the dependency on python entirely seems fine to me. The technically most correct solution would be to split etckeeper into multiple packages along the lines of etckeeper-common etckeeper-git (Depends: etckeeper-common, git) etckeeper-bzr (Depends: etckeeper-common, bzr, python2) etckeeper (Depends: etckeeper-git | etckeeper-bzr) But considering how tiny these would be and the overhead and expense involved, this I don't feel it would be worth it. It would also be a backwards-incompatible change for non-git users, since APT has no way to pick the correct variant. > In fact, looking at #906000 again, I'm not sure that's the right > solution either. To quote that bug report: > > > etckeeper installs a Python module but no longer has a python > > dependency. > > If we remove the Python dependency, we reopen that bug. I'm not sure > what the implications of that are. I don't suppose it is an option to retroactively mark it INVALID? While I understand that packages of python modules need to depend on python, and packages that include python modules need to consider whether they require a dependency on python, such a dependency is neither needed nor desired in this case. > Bug #883146 tracks bzrlib python3 support. Upstream has released "3.0 > pelican" that ports to py3, but that hasn't landed in Debian > yet. There's also #883145 which explicitely requests etckeeper to be > ported to python3. A dependency on python3 would certainly be less offensive, but it would still be inappropriate and may end up unnecessarily pulling in python3 on systems where it was not previously installed.
