svn commit: r446864 - head/sysutils/py3-iocage

[Bryan Drewery]

On 7/31/2017 3:28 AM, Kubilay Kocak wrote:
> On 7/31/17 8:07 PM, Baptiste Daroussin wrote:
>> On Mon, Jul 31, 2017 at 05:03:35PM +0800, Marcelo Araujo wrote:
>>> 2017-07-31 10:35 GMT+08:00 Kubilay Kocak <koobs at freebsd.org>:
>>>
>>>> On 7/31/17 11:16 AM, Marcelo Araujo wrote:
>>>>>
>>>>>
>>>>> 2017-07-30 21:18 GMT+08:00 Adam Weinberger <adamw at adamw.org
>>>>> <mailto:adamw at adamw.org>>:
>>>>>
>>>>>     > On 28 Jul, 2017, at 22:17, Marcelo Araujo <araujo at freebsd.org
>>>>>     <mailto:araujo at freebsd.org>> wrote:
>>>>>     >
>>>>>     > Author: araujo
>>>>>     > Date: Sat Jul 29 04:17:31 2017
>>>>>     > New Revision: 446864
>>>>>     > URL: https://svnweb.freebsd.org/changeset/ports/446864
>>>>>     <https://svnweb.freebsd.org/changeset/ports/446864>
>>>>>     >
>>>>>     > Log:
>>>>>     >  - Update to 0.9.9.
>>>>>     >
>>>>>     >  Changelog at: https://github.com/iocage/iocage/releases/tag/0.9.9
>>>>>     <https://github.com/iocage/iocage/releases/tag/0.9.9>
>>>>>     >
>>>>>     > Modified:
>>>>>     >  head/sysutils/py3-iocage/Makefile
>>>>>     >  head/sysutils/py3-iocage/distinfo
>>>>>     >
>>>>>     > Modified: head/sysutils/py3-iocage/Makefile
>>>>>     >
>>>>>     ============================================================
>>>> ==================
>>>>>     > --- head/sysutils/py3-iocage/Makefile Sat Jul 29 04:00:56 2017
>>>>>         (r446863)
>>>>>     > +++ head/sysutils/py3-iocage/Makefile Sat Jul 29 04:17:31 2017
>>>>>         (r446864)
>>>>>     > @@ -1,7 +1,7 @@
>>>>>     > # $FreeBSD$
>>>>>     >
>>>>>     > PORTNAME=     iocage
>>>>>     > -PORTVERSION= 0.9.8.1
>>>>>     > +PORTVERSION= 0.9.9
>>>>>     > CATEGORIES=   sysutils python
>>>>>     > PKGNAMEPREFIX=        ${PYTHON_PKGNAMEPREFIX}
>>>>>     >
>>>>>     > @@ -15,6 +15,7 @@ BUILD_DEPENDS=
>>>>>     ${PYTHON_PKGNAMEPREFIX}pytest-runner>=2
>>>>>     > RUN_DEPENDS=  ${PYTHON_PKGNAMEPREFIX}click>=6.7:devel/py3-click \
>>>>>     >               ${PYTHON_PKGNAMEPREFIX}tqdm>=4.10.0:misc/py3-tqdm \
>>>>>     >
>>>>>      ${PYTHON_PKGNAMEPREFIX}coloredlogs>0:devel/py3-coloredlogs \
>>>>>     > +
>>>>>      ${PYTHON_PKGNAMEPREFIX}verboselogs>0:devel/py-verboselogs \
>>>>>     >               ca_root_nss>0:security/ca_root_nss \
>>>>>     >
>>>>>      ${PYTHON_PKGNAMEPREFIX}texttable>=0.8.7:textproc/py3-texttable \
>>>>>     >
>>>>>      ${PYTHON_PKGNAMEPREFIX}pytest-runner>=2.0.0:devel/py3-pytest-runner
>>>>>
>>>>>     Hi Marcelo,
>>>>>
>>>>>     There is no py36-verboselogs package. You'll need to create a
>>>>>     py3-verboselogs port, because right now only py27-verboselogs gets
>>>>>     built.
>>>>>
>>>>>     See the build failure at
>>>>>     http://beefy10.nyi.freebsd.org/data/110i386-default/
>>>> 446906/logs/py36-iocage-0.9.9.log
>>>>>     <http://beefy10.nyi.freebsd.org/data/110i386-default/
>>>> 446906/logs/py36-iocage-0.9.9.log>
>>>>>
>>>>>     # Adam
>>>>>
>>>>>
>>>>>     --
>>>>>     Adam Weinberger
>>>>>     adamw at adamw.org <mailto:adamw at adamw.org>
>>>>>     https://www.adamw.org
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> We can't add py3 ports because soon we gonna have FLAVORS!
>>>>> I can build iocage if I define the python version on my make.conf,
>>>>> however I can see the issue with poudriere.
>>>>
>>>> Since this port already uses py3-* (workaround) ports for dependencies
>>>> and there is no known ETA for VARIANTS support in ports, and the port is
>>>> broken without py3-verboselogs, it should be created.
>>>>
>>>> Also, py-iocage should be resurrected, py-iocage was incorrectly deleted
>>>> [1] instead of this one when it moved to Python 3.x only support. py3-*
>>>> ports are only for (temporary) dependencies
>>>>
>>>> [1] http://svnweb.freebsd.org/changeset/ports/445459
>>>
>>>
>>> How I can pass the pre-commit hook that blocks any add of py3 slave ports?
>>>
>>> Best,
>>>
>>
>> FLAVORS are in review and finished, poudriere is able to deal with them -devel.
>>
>> The commit is pending exp-run, documentation etc. It takes time as it is a major
>> change in the framework with huge impact.
>>
>> py3-* were a hack in the first place that should never have been done, they
>> addition made it more complicated to work on FLAVORS, adding more and by passing
>> the hook would just give even more delay for FLAVORS to be committed.
> 
>> Best regards,
>> Bapt
>>
> 
> Existing ports (particularly popular ports like iocage) that already
> rely on these dependencies should be allowed continue to work. The block
> relies on the assumption that new dependencies for existing and working
> ports will never be needed, which is the case here.
> 
> The block on new py3-* ports (while noone likes them) was and is
> premature, and is even more so without an alternative, and it was
> heavy-handed. Developers were already trying hard to minimise their use.
> 
> The block should be removed, and can be re-added when the official
> package builders are running with the poudriere "special feature"
> version that builds py3-* versions of py- ports automatically, or ports

I'm not quite awake yet so pardon the terseness.  I will start a
poudriere-devel exp-run now and then push it out to the builders
following that in the next 2 days.  That will allow py3- dependencies to
build properly.  It would allow existing py3- leaf ports to build as well.

As for py3- leaf ports I would allow them but they have to follow strict
criteria:
- They must be named category/py3-foo
- They must be a *slave* port to a category/py-foo
- They must be supported on all python versions, not just 3.4+ or
something odd like that.

The FLAVORS support in Poudriere is done. What is held up is an exp-run
that I'm tasked with and various bugs/documentation/more exp-runs.
Every new py3- port added that doesn't follow those rules means we have
to change Poudriere again.  I think the criteria above is reasonable but
I know the last one is problematic.

I've said on IRC before but not sure I have here, that py3- ports beyond
the fixed cases above, are only useful for generating a leaf package for
users to download.  They can still build category/py-foo as PYTHON3
today though.  So there is an alternative but it is just not
package-friendly yet.

About the block being premature, I will agree that what was lacking was
a communication about it to a wider community and an override allowed
with Portmgr review.  At the time I wasn't quite sure what the criteria
for an override would even be.  Now that I understand it more and have
Poudriere being a bit smarter than my first implementation, I will tweak
the block to allow a Portmgr override.

> variants supports lands, whichever one comes first. If that's in 3 days,
> great, if its in 3 weeks or 2 months, our developers have been allowed
> to keep the status quo working.
> 
> Users are currently being impacted where there is no alternative and
> they should not be asked to pay that price for our dislike of py3-* ports.
> 
> Best regards,
> Koobs
> 


-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/svn-ports-all/attachments/20170731/59fcb146/attachment.sig>