Re: postorius, v2

[Hartmut Goebel <h.goebel@crazy-compilers.com>]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

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?


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.


-- 
Regards
Hartmut Goebel

| Hartmut Goebel          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |


[-- Attachment #2: 0xBF773B65.asc --]
[-- Type: application/pgp-keys, Size: 14855 bytes --]