LGTM for devel/py-keystone-engine and lang/python310.

In D31782#718446, @koobs wrote:

I'm -1 on a new/separate variable, and maintain that having an expiration date (end-of-life etc) being 'deprecated' (now) logically and semantically makes sense. The reason why porters handbook
says otherwise [1] is because these variables have ports/framework/implementation specific meanings, somewhat more overloaded than a pure metadata or only-descriptive definition. For example EXPIRATION_DATE is used to delete ports, where from a maintainer perspective, its valuable to be able to describe an end-of-life date at any time, all the way from port creation to the time its deleted. This would for example allow for automatic 'messages' to users as they 'approached' that date, progressively getting 'stronger' as they got closer.

[1] "It is possible to set DEPRECATED without an EXPIRATION_DATE (for instance, recommending a newer version of the port), but the converse does not make any sense."

Address @koobs's suggestions regarding the deprecation messages.

Address @koobs's suggestions regarding the deprecation message.

To resume @koobs's suggestion from D30977 (https://reviews.freebsd.org/D30977#700968) regarding setting only EXPIRATION_DATE:

FWIW, I also came across it some time ago while working on www/qt5-webengine. The issue with grep -q can be reproduced quite well on i386 platforms with quite large files and I had already created a PoC for this, but since then I haven't had time to follow it up more closely.

In D30977#701350, @sunpoet wrote:

In D30977#700968, @koobs wrote:

Can we sort out the category for django-rq (to www/) before this change lands?

I'm not sure if we have to put django-* in www.
At least we have:

• devel/py-django-rq
• graphics/py-django-easy-thumbnails
• mail/py-django-mailbox
• mail/py-django-mailman3

In D30977#701349, @sunpoet wrote:

In D30977#697015, @kai wrote:

@sunpoet: It's ok with you if you take maintainership of the new ports devel/py-dj32-django-rq , www/py-dj32-django-debug-toolbar and www/py-dj32-django-redis ?

I'm OK this that.
BTW, I'll put NO_ARCH before CONFLICTS_INSTALL.

• Move devel/py-dj32-django-rq back to devel/
• Set @sunpoet as maintainer for devel/py-dj32-django-rq, www/py-dj32-django-debug-toolbar and www/py-dj32-django-redis and change the order of CONFLICTS_INSTALL and NO_ARCH there as well.

In D30977#700968, @koobs wrote:

Can we sort out the category for django-rq (to www/) before this change lands?

• Place py-dj32-django-rq to the www category as suggested by @koobs.

• Assume maintainership of the new ports devel/py-dj32-django-rq, www/py-dj32-django-debug-toolbar and www/py-dj32-django-redis as well.

@sunpoet: It's ok with you if you take maintainership of the new ports devel/py-dj32-django-rq , www/py-dj32-django-debug-toolbar and www/py-dj32-django-redis ?