On 10/29/26 05:57, Dan Langille wrote: > On Wed, Oct 28, 2026, at 01:21, Daniel Engberg wrote: >> On 2026-10-28 01:17, Kevin Oberman wrote: >>> On Tue, Oct 27, 2026 at 7:12 AM Daniel Engberg <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> On 2026-10-27 09:50, Jochen Neumeister wrote: >>> > Hi all, >>> > >>> > Robert's proposal touches a real problem: ports that stay BROKEN for >>> > months while nobody feels responsible. Releasing such ports to ports@ >>> > can help, because it makes clear that anyone may step in and fix >>> them. >>> > To Gleb's point, it should not hit active maintainers who set BROKEN >>> > on purpose while waiting for an upstream release. >>> > >>> > What I miss in this thread is the order of steps. Most of the >>> > discussion is about when a port may be removed. Shouldn't the first >>> > goal be to fix it? >>> > >>> > If a project is dead, for example the repository has seen no activity >>> > for years and the code no longer builds, there is nothing wrong with >>> > removing the port. If the project is alive, the port should get the >>> > chance to be fixed first. For Budgie, the fix had been available >>> > upstream since November 2025 (10.9.4). For filesystems/darling-dmg, a >>> > patch had been waiting in Bugzilla since September 27 (PR 298920), >>> > and the maintainer timeout had already expired. Both ports were >>> > removed anyway. Restoring, fixing and testing both took one evening, >>> > which is less time than all of us have spent on this discussion. >>> > >>> > These are not isolated cases. On October 4, 19 and 26 alone, 27 ports >>> > were removed from the tree in 21 commits because they were marked >>> > BROKEN. None of them had been deprecated with DEPRECATED and >>> > EXPIRATION_DATE first. Two of them were not even broken themselves, >>> > they only depended on a broken port. Users of these ports had no >>> > chance to speak up. >>> BROKEN stops generating packages, adding PORTREVISION, DEPRECATED etc >>> wont do anything as that isn't propagated to pkg "top" metadata. >>> >>> Running "pkg update" and "pkg upgrade" doesn't notify of anything, even >>> if the package is gone from upstream repo. >>> >>> So adding DEPRECATED etc will do nothing in practice because that >>> information will never be propagated because the port (package) isn't >>> built in the first place. >>> >>> If you're using ports you'll already see BROKEN. >>> >>> It's applicable as long as the port actually builds however. >>> >>> I see that Daniel is possibly unaware that DEPRECATED does do something >>> if you have the port in question installed. The periodic output, by >>> default, prints a list of all packages that have security issues in the >>> CVE and all ports that are deprecated. It also shows the date when the >>> port may be deleted. Assuming you run periodic/security, the log takes >>> care of making it evident to those using the port that it is deprecated >>> every day. E. g. "xmlto-0.0.28_3: Tag: deprecated Value: Depends on >>> vulnerable libxslt" and "xmlto-0.0.28_3: Tag: expiration_date Value: >>> 2025-12-31". >>> -- >>> Kevin Oberman, Part time kid herder and retired Network Engineer >>> E-mail: [email protected] <mailto:[email protected]> >>> >> >> Hi Kevin, >> >> You're are correct in the sense that it does something but IF the port >> actually builds (and is installed). It doesn't work on ports that fails >> to build and generate packages. > > Case in point, this is an extract from the system emails I receive. > > Checking for packages with security vulnerabilities: > Host system: > Database fetched: 2026-10-27T08:15+00:00 > oniguruma-6.9.10: Tag: expiration_date Value: 2026-12-01 > oniguruma-6.9.10: Tag: deprecated Value: Project archived upstream > > Are you saying that if oniguruma is failing to build, these messages do not > appear? >
I expect that the answer is: Failing to build means that no package was produced, thus that "build" of the port will not be in a list of packages with security vulnerabilities. Any list entry would be from an older package variant that was still installed. I also would expect that only installed packages show up in such a report, not everything that was only built. If a report was based on a ports source tree instead of based on installed packages, then it would not be limited to what is installed or what is built. A report based on package repositories that are present would report based on what has build(s), not based on what was installed. -- === Mark Millard marklmi at yahoo.com
