Re: Packaging dependencies for mailman3-hyperkitty
On Thu, Mar 24, 2016 at 11:43 PM, Pierre-Elliott Bécue wrote:
> Packaging dependencies for mailman3-hyperkitty
Does HyperKitty depend on mailman3 or just enhance it by providing an
archive web interface? If the latter, I would suggest calling it
hyperkitty instead of mailman3-hyperkitty.
> robot-detection suffers the same illness, but it's tiny, it's possible to
> integrate it in hyperkitty, or make it optionnal.
Embedded code copies are against Debian policy, please package it
separately or get upstream to switch to something else.
https://wiki.debian.org/EmbeddedCodeCopies
Something like that sounds like it isn't possible to keep usefully
up-to-date in Debian stable though, since the landscape of robots on
the web will be changing continually and many will be aiming to
emulate browsers.
https://pypi.python.org/pypi/robot-detection
In addition, it seems to be woefully inadequate for that since the API
doesn't appear to take into account IP address ranges.
It also depends on the robotstxt.org database, which would need to be
packaged separately and is also no longer kept up to date at this
time:
http://www.robotstxt.org/db.html
"This robots database is currently undergoing re-engineering. Due to
popular demand we have restored the existing data, but
addition/modification are disabled."
As the page says, there is a better database of user-agents available
http://www.botsvsbrowsers.com/
http://www.botsvsbrowsers.com/category/1/index.html
Unfortunately this is incompatible with the data format used by
robotstxt.org/robot-detection:
http://www.robotstxt.org/db/all.txt
So you can see from the botsvsbrowsers.com data, the User-Agent field
is often bogus or contains vulnerability attack patterns and is thus
mostly not useful at all and should probably just be ignored by all
web apps at this point.
So I would suggest convincing upstream to remove whatever use of
robot-detection is present in mailman3 or hyperkitty.
> That leaves me with django-gravatar2, that seems useful, and is still
> developed. I heard there is some kind of "canonical" way of packaging django
> apps. As I'm not used to that, I'm here to ask advice.
I would suggest upstream switch from Gravatar (a centralised
proprietary service) to Libravatar (a federated Free Software service
that falls back on Gravatar):
https://www.libravatar.org/
Re canonical django packaging, you may be talking about this:
https://wiki.debian.org/DjangoPackagingDraft
There are also lots of python-django-* packages in Debian that you
could look at.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Reply to: