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? -- Dan Langille [email protected]
