On 12/21/2016 01:23, Jim Trigg wrote:
No, that's not what I'm saying. I can't find anything online showing
that this problem has been reported.

I've see this reported before, probably on this list, maybe by you.

I can't reproduce it using the tool
that I've been using for years (portmaster).

Which by itself only indicates a portmaster weakness.

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.

Okay, good.
Any time you can produce an error with poudriere, it should be easy for others to reproduce as well which confirms the error.

Honestly, if personX reports an error, tells me he uses portmaster, and not not try to reproduce with poudriere, I (and likely most committers) will disregard the report -- or at the very least ask them to report back if they can confirm with poudriere.

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.

Did you open a PR on https://bugs.freebsd.org/bugzilla/ ?
Once you report something, after 2 weeks of inactivity you have the right to ping this list (in the worst case of your report being ignored).

It's not the tool's fault when the port itself is broken and the port can't be fixed if nobody reports issues with non-default options.


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...

yes. It's not a subjective thing. Anybody that knows what they are talking about agrees. If anyone tries to sell you that portmaster is "just as good" as poudriere, they are at best ignorant as hell.

You bring up a real-life case right here in this thread.

Never mind that the whole pkgng system was forced on us
willy-nilly, and it's the main reason there are problems with
portmaster.

wow. No, this is absolutely false. You need to cleanse your head from thoughts like these. The only role pkgng even has in building is physical packaging and basic dependency checking. None of that has *anything* to do with the fundamental issues of 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.)

Luckily you don't need to contest it. A clock is a clock, a benchmark is a benchmark, and they are by design, objective. Doing the same exact set of tasks, Synth will do the job much faster. It's objectively much faster to set up.

Subjectively people say it's easier for new users to grasp.

There are a couple of specific features poudriere does that synth does not (e.g. cross building with QEMU and blocking network during build phase) but the vast majority of users don't require these features and if they do, poudriere is the only game in town.

JOhn


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"

Reply via email to