The ports collection has some serious issues

[Jim Trigg]

On 12/19/2016 09:02 AM, John Marino wrote:
> On 12/18/2016 23:42, Jim Trigg wrote:
>> On 12/18/2016 02:24 AM, John Marino wrote:
>>> 2) portmaster's dirty build method is inferior to clean environment
>>> builds (true)
>>> 3) There is better and official alternative (true)
>>
>> Maybe. I have a case where portmaster (on my current production box)
>> builds fine but poudriere (on my intended replacement production box)
>> does not.
>>
>> Case in point: php70-pdo_*. The first time I tried a build pdo_sqlite
>> failed. This time (after correcting other ports' option problems)
>> pdo_mysql fails for basically the same reason - pdo_* cannot find pdo
>> because pdo thinks PHP_EXT_DIR=20151012-zts but pdo_* thinks
>> PHP_EXT_DIR=20151012 - log for the latter below signature. Yet doing the
>> build with postmaster works fine.
>
> Wasn't that a global bug that was fixed?7

I don't know; I can't find any record of it...\

> You logic is faulty IMO.  All binary packages produced officially for
> FreeBSD are built with poudriere.  If poudriere can't build it due to a
> bug in the port itself, then nobody gets the package.  Obviously that's
> unacceptable, so the port bug gets fixed, quickly.

All binary packages produced officially for FreeBSD are built with 
poudriere *with default options*. ZTS is not the default (even though 
it's needed in most cases for mod_php and apache).

> So it sounds like you're saying that poudriere is too strict at
> enforcing correctness and you need something more forgiving?

No, that's not what I'm saying. I can't find anything online showing 
that this problem has been reported. I can't reproduce it using the tool 
that I've been using for years (portmaster). Therefore my first 
assumption was that the problem was the new tool I had just started 
using. Note: while my phrasing may have been poor, I was not meaning to 
imply that the tool (poudriere) was necessarily broken, just that I 
couldn't figure out what was going wrong and that it seemed (based on my 
data sample) to be poudriere rather than the port. Having now tested 
using the ports tree directly (make -C 
/usr/ports/databases/php70-pdo_mysql on a basically clean ports tree 
with "OPTIONS_SET+= ZTS" in /etc/make.conf) and gotten the same failure 
as with poudriere, I now have no idea how it worked in portmaster, and 
acknowledge that it is a problem with the port.

> Unfortunately, port maintainers break the tree.  Usually the big breaks
> are avoid with EXP-RUNs but it's common to see updates where downstream
> dependencies weren't tested and break (aside: IMO this it is the
> responsibility of the person updating the first port to verify the deps
> still build but not everyone does this).
>
> So sometimes you hit a tree break and that's what happened.  It was
> fixed right?  The bottom line: if a port doesn't build on poudriere and
> synth, the issue must be fixed, not worked around by using a tool
> incapable of detecting it.  That's how most of the "I use portmaster and
> this doesn't work" topics get started.

It doesn't seem to have been fixed, since I'm still seeing the error. 
I'm saying that 90% of the time portmaster works for me, and when it 
doesn't I can figure out a solution 90% of that time. I haven't gotten 
poudriere to work for me yet given the set of options I need set.

>>> 4) There's a second, even more effective alternative for x86 platforms
>>> (true)
>>
>> I can not as yet contest this. I haven't tried synth because if
>> poudriere works it will have further value add for me (as a port
>> maintainer I can build my port in multiple environments on a single
>> box). Dealing with the conversion factor isn't worth it to me for the
>> alleged gains synth brings.
>
> I am a big supporter of poudriere.  While many people find they prefer
> synth and enjoy its performance advantage, I will never tell a poudriere
> user to switch if they are happy with poudriere.

But you will tell a portmaster user to switch if they are happy with 
portmaster because it doesn't do things the way you think they should be 
done... Never mind that the whole pkgng system was forced on us 
willy-nilly, and it's the main reason there are problems with 
portmaster. Note that the "cannot as yet contest this" is because I'm 
not convinced that synth is "more effective" than poudriere - I expect 
that they are each better suited for a particular use case. The 
difference is that as far as I can tell, poudriere is satisfactory for 
the use case synth is designed for, but synth is not suited for the use 
case poudriere was initially intended for. (Note that a primary use of 
poudriere is/was to replace the now extinct port tinderbox.)

Jim Trigg