Quoting Afif Elghraoui (2017-06-07 01:44:45) > > على الثلاثاء 6 حزيران 2017 04:42، كتب Jonas Smedegaard: >> Quoting Ghislain Vaillant (2017-06-06 10:13:55) >>> >>> Given this is a Python package, we should not even have to argue >>> about package relationships. Setuptools metadata provides >>> install_requires and extras_require, the former mapping to Depends, >>> the latter to Suggests. Period. >>> >>> Your typical Python project README would instruct users to install >>> the Python package via `pip install`. If one runs `pip install >>> networkx`, the graphics dependencies do not get pulled. That alone >>> is enough to justify that these dependencies should not go to >>> Recommends. >>> >>> FYI, I have a similar problem with sympy (#861741), which pulls an >>> insane amount of packages via chained Recommends. >> >> We should certainly continue to align package relations with Debian >> Policy - and therefore by extension continue to argue about that as >> necessary to evolve Debian Policy: >> >> Upstream (or other) package relation hints can be a valuable _aid_ in >> resolving Debian package relations, but only that: An aid! >> >> Debian packaging follows Debian Policy - other hints do not. >> > > Both good points, but upstream is in the best position to decide > whether something is a strong-yet-not-absolute-dependency (Recommends) > of their software. What Ghislain is saying about Python packages here > makes a lot of sense to me.
Upstreams of Python projects are "in the best position to decide" about _PyPI_ hinting. What we discuss here is _Debian_ hinting, which is not necessarily the same, even if labels are identically/equivalently named. Debian maintainers are in the best position to decide about Debian hinting. Taking upstream hinting into consideration is quite sensible, but *not* authoritative not "best" for _Debian_ hinting. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
