Date: Wed, 21 Dec 2016 05:32:55 -0600 From: John Marino <freebsd.contact@marino.st> To: Jim Trigg <jktrigg@gmail.com> Cc: "ports@FreeBSD.org Ports" <ports@FreeBSD.org> Subject: Re: The ports collection has some serious issues Message-ID: <e859b1f3-3147-aa98-fce9-9c351e7991c0@marino.st> In-Reply-To: <8a915b99-6c8b-4ed0-580c-d2be76f745d1@gmail.com> References: <e2fb7eec-b894-a1e4-eb6d-2e1c5b500a44@marino.st> <20161218013548.GA25190@server.rulingia.com> <3c83b1e8-4428-ddcf-9b55-3793e098c6af@marino.st> <20161218064332.GA16173@eureka.lemis.com> <d64a3e0b-f9b1-0f0f-6459-ea41374cef5e@marino.st> <4f2e93f8-1988-ff60-1159-0daee695836a@gmail.com> <6e78c9cc-8f08-d7c3-6f62-0c0525fa3fea@marino.st> <8a915b99-6c8b-4ed0-580c-d2be76f745d1@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e859b1f3-3147-aa98-fce9-9c351e7991c0>