On 2026-10-29 13: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?
If we take that port as an example, if you'd have a "freshly"/rebuilt
package built you wouldn't have that message at all.
https://cgit.freebsd.org/ports/tree/devel/oniguruma/Makefile
https://cgit.freebsd.org/ports/tree/devel/oniguruma/Makefile?h=2026Q4
https://cgit.freebsd.org/ports/commit/devel/oniguruma/Makefile?id=16ee1dff104b5108d7ed6c18b909ad603754d2ed
Lets say oniguruma starts failing to build/package today.
As long as nothing triggers Poudriere to rebuild the port or build
everything from scratch it'll still be in the repo in its last working
form. However, if something does Poudriere will remove the existing
package as it's scheduled to rebuild it. If it fails during the run
Poudriere will rebuild the repo without the failing port (oniguruma) and
it'll show up in pkg-fallout.
Running pkg update or pkg upgrade won't tell you anything about a
package missing "upstream" but exists on your client.
Otherwise it'll be like any other package that doesn't exist.
Best regards,
Daniel
