Hartmut Goebel writes: > Hi, > > I just found that I did not verify the inputs carefully enough. Sorry. > Here are my comments: > > * python-defusedxml: okay > * python-openid: okay > * python-django-allauth: > o openid, request-oauthlib requests ought to be propagated inputs > o mock is native, okay, but only required for the python2 variant > o Why is django a native input? See below for discussion > * python-django-gravatar2, may be okay, see below for discussion. > * python-django-mailman3 > o All "inputs" except django need to be propagated inputs. > o Regarding django: see below > * * postorius: okay (this is an application, so no propagated inputs > are required) > > > And as we just learned about the licenses: python-django-mailman3 should > be gpl3+ > > > I'm unsure about the correct handling of django in django-XXX. Can we > find rules for this to make future packager's life easier? > > Should django be a "normal" input or a "native" one? What does this > depend on? >
For now I will go with (input) and not (native-input). If that's not okay, we can still fix it afterwards? I will send the new patchseries tomorrow. Thanks! > Clear is: django-XXX should not "propagate" django: > > * django is a framework, django-XXX is an extension for this framework. > * If some application is using django-XXX, I'd expect it to have > django specified as "input", too, since primary it is a django > application. Maybe even djangoXXX is an optional component > > > Just for the records: > > * django-XXX should propagate other django extension it requires. > o If some application is using django-XXX, if should not care > about other django extensions django-XXX requires. This is the > same like as it does not have to care about other python > packages django-XXX requires. -- ng0 . https://www.inventati.org/patternsinthechaos/