The ports collection has some serious issues
freebsd.contact at marino.st
Wed Dec 21 11:32:57 UTC 2016
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.
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
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
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.
This email has been checked for viruses by Avast antivirus software.
More information about the freebsd-ports