Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Dec 2013 16:54:22 +0000
From:      William Grzybowski <william88@gmail.com>
To:        John Marino <marino@freebsd.org>
Cc:        python <python@freebsd.org>
Subject:   Re: Any fixes in work for py-setuptools for python 3.3+ ?
Message-ID:  <CAHtVNLP06eGCxwdCDzEsFWbe1Jjairn3X3jMy=5eJnu9RGFn4g@mail.gmail.com>
In-Reply-To: <52B9B9AF.7050400@marino.st>
References:  <52B9B5C4.8050101@marino.st> <CAHtVNLN1EZzN=RPFy_p=CUAc_Vy5TK0-00tEaBTECT2XKaJavQ@mail.gmail.com> <52B9B9AF.7050400@marino.st>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 24, 2013 at 4:43 PM, John Marino <freebsd.contact@marino.st> wrote:
> On 12/24/2013 17:33, William Grzybowski wrote:
>> On Tue, Dec 24, 2013 at 4:26 PM, John Marino <freebsd.contact@marino.st> wrote:
>>> Recently, probably caused by recent changes to devel/py-setuptools,
>>> around 6 ports broke all in the same way.  An example is below:
>
>>> Is python@ aware and are these ports going to be restored?
>>> I can provide a list of the broken ports I've seen so far if not.
>>
>> These are not port breakages.
>>
>> poudriere builds only one package per port, devel/py-setuptools builds
>> py27-setuptools because python.27 is the default version.
>>
>> sysutils/brebis for instance, can only work for python 3.3+, it
>> depends on setuptools but it cant build because setuptools was built
>> for the default version.
>>
>> It was not a problem before in poudriere because setuptools was not a
>> build dependency.
>
> Are you telling me that it is impossible to provide these ports as
> binary packages?  Personally, I see a regression because they were
> building before.  Now they aren't (as you mention above).

Using poudriere, yes, it seems to be the case.

> The impact is that they will disappear from dports, because we don't
> feature ports that can't have binary packages.  I'm sure there was a
> good reason for the change that caused these ports not to build in
> poudriere, but that change did cause damage.  I'm not in a position to
> say if the tradeoff is worth it because I don't understand what was
> gained (only what was lost).

If you want to provide packages with the non-default python version
you can use DEFAULT_VERSIONS= python3.3 for your poudriere make.conf.

The issue here is that the dependency list is built with poudriere
using PKGORIGIN, however py-setuptools can have several distinct
PKGNAME, depending on your chosen python version.
We are not going to provide a new port for every python version of a package.




-- 
William Grzybowski
------------------------------------------
Curitiba/PR - Brasil



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHtVNLP06eGCxwdCDzEsFWbe1Jjairn3X3jMy=5eJnu9RGFn4g>