> On May 8, 2025, at 01:05, John W <jwde...@gmail.com> wrote: > > I know that using binary packages is popular these days, and that poudriere > exists, too. But I still generally have been managing my ports via 'make > install' and/or portmaster (which uses the same, under the hood). > > But I had a strange interaction in a bug report, recently [1], which makes me > wonder: is this old style of managing ports no longer well-supported? > > Quote from that link from bofh@: > > And to be frank for end users; ports is not the way to go. It's > binary pkgs or poudriere for your custom builds. If you want to try > ports/portmaster/portupgrade seek help from forums or mailing lists not > as a bug report. > > As far as I am able to tell, the behavior I described *is* a bug with that > port. But the fact that it manifests via 'make config' and soforth seemed to > be a reason for it to not be considered a bug? > > As I understand it, bofh@ is a senior FreeBSD person, so presumably they know > more about it than I do. But I could not find a way to make sense of their > response without the impression that make-based workflows are not supported, > these days. > > Just curious if anyone else has some high-level insights on this situation. > I've been using 'make install' for like 15+ years and it seems weird to get > this sort of response from ports maintainers. > > -John > > > [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286659#c4
Hi John, Let me be blunt — because I think the situation calls for it. You originally filed a bug about `make config-conditional`, which I closed after evaluating it within the scope of current project practices. Instead of following up appropriately or acknowledging that your workflow might be out of sync with supported expectations, the conversation was derailed into a completely unrelated issue: the ASYNCIO option — which had already been removed from the tree months prior[1]. When you followed that up with a second bug focused on the ASYNCIO option — it became clear that your ports tree is significantly outdated. That option has long since disappeared from the active ports tree and a full quarterly cycle has passed. You are, effectively, filing bugs against a snapshot of FreeBSD that the project no longer supports. That was not only a hijack of a closed ticket — it turned into a demand that I read and respond to a bug report built entirely on stale ports tree state from 2023. From my side, that’s not just frustrating — it’s a waste of time. As a volunteer maintainer with limited bandwidth, I cannot and will not invest effort in reconstructing expired environments just to debug issues that no longer exist upstream. The bug tracker is not a time machine. This is not about being hostile to `make install` or `portmaster` users. It’s about scope and sustainability. The FreeBSD ports tree is under continuous development. If you’re filing bugs against outdated snapshots — with stale options, outdated configs, or assumptions that haven’t held for multiple quarterly cycles — then you’re not reporting problems in supported code. You're asking others to chase ghosts. More broadly, I want to address a persistent myth: that poudriere is "just one option." That’s false. Poudriere is the standard build infrastructure for the FreeBSD project. It’s how we generate every binary package shipped through pkg. It’s what we test. It’s what we validate. If poudriere weren’t the baseline, the project wouldn't use it for its public-facing deliverables. So when someone says “poudriere isn’t required,” the follow-up question should be: then why does the project itself depend on it completely? Poudriere exists precisely to avoid these problems: it gives you clean, reproducible builds that reflect the real state of the tree — not whatever cruft is left behind in /var/db/ports or custom local configs or polluted environment. If you aren’t using poudriere and aren’t tracking HEAD or a supported quarterly snapshot, you’re on your own. That’s the reality — not out of hostility, but necessity. So yes, my response in the bug was blunt. And I stand by it. I’ll always be happy to triage real issues affecting the current tree. But I will not be pulled into time sinks caused by outdated environments, hijacked bugs, or community members who offload the cost of their own poor practices onto others. There’s a reason I redirected you to forums or mailing lists: if you insist on using make install, portmaster, or other non-standard workflows, that’s fine — but support for those approaches lives in the community, not the developer workflow. To summarize: the ports tree evolves rapidly. If you're going to file bugs, it's your responsibility to ensure you're working with current, supported code. Otherwise, you're not reporting bugs — you're generating churn. Regards, Moin [1]: https://cgit.freebsd.org/ports/commit/www/py-autobahn/Makefile?id=9e57c3eb5ef41bc82493a55af76a097e0f77d7a5
signature.asc
Description: Message signed with OpenPGP
