- Kyua is part of the base in all supported versions - Kyua's evolution happens in the base, let's avoid double work - Set EXPIRATION_DATE to 2026-04-30 (expected 13 branch EOL)
Details
Diff Detail
- Repository
- R11 FreeBSD ports repository
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
So far, I remember that I took over the maintainership while the original author did not have time to focus on this and handed over the repo to our project. I also merged some of the upstream codes in the base. So, I am adding others who were involved in that process at that time. However, I do not have any objection to this review at all.
But as the other two mentioned here are AFK in the FreeBSD summit, I would request you to wait until they return to provide feedback.
Seems fine to me. I don't know the ports framework well enough to give a proper review, but the plan is good.
But as the other two mentioned here are AFK in the FreeBSD summit
I am at home. :)
devel/kyua/Makefile | ||
---|---|---|
17 | This seems very conservative, but I'm not sure what a typical port deprecation schedule looks like. | |
46 | So if someone on 14.2 runs "pkg upgrade", they will silently stay on their old kyua pkg. It'd be nice if we could report this problem to them somehow, but I don't know if there's a mechanism to do that. |
devel/kyua/Makefile | ||
---|---|---|
17 | Last day of quarterly or 1 month whichever is greater. But we do have expirations dated 1 year from now too. | |
46 | The MOVED takes care of this in the build mech for poudriere. But if you are not using pkg autoremove it piles up. For now, there is actually no mechanism to force the removal of this. |
devel/kyua/Makefile | ||
---|---|---|
46 | IIRC, pkg version should report package status like ? for removed/moved ports. So that users are expected to pay attention to that. It's expected to provide an extra assistance for this migration process. |
devel/kyua/Makefile | ||
---|---|---|
46 | Aha, actually not, that should happen after 2026-04-30. |
devel/kyua/Makefile | ||
---|---|---|
46 | Those are better than nothing; I was just hoping that pkg would print a message after the upgrade to the effect of, "devel/kyua is not supported on 14.2 or later, be sure to remove it". |
Just BUMP PORTREVISION and merge it quarterly. You will be absolutely sure that everyone will know about it if they upgrade their pkg in next 6 months.
Bump PORTREVISION with the expectation that users will see the deprecation notice upon upgrade.
I see the currently proposed change as the following outcome:
- 13.x users should stay as is with old test suite and old Kyua from base or port/pkg. And the pkg is expected to be still cooked till 13 branch EOL.
- 14.x users are expected to find kyua pkg missing after upgrade to the latest port branch. They are expected to do such upgrade with OS upgrade as well, i.e. up to 14.2, which has the test suite aligned with Kyua in its base. 14.0 and 14.1 users of older Q branches are expected to use the same older suite and pkg. Even if they upgrade only ports having old 14.0 or 14.1 then they still have the test suite runnable with Kyua in their base.
- Just in case, the port is still available for anyone till 13 EOL (30 April 2026).
- A port/pkg update is expected to show the deprecation notice. It should cover attended cases.
I hope I'm not missing a thing here.
devel/kyua/Makefile | ||
---|---|---|
48 | In our case, we can do it like: .if ${OPSYS} == FreeBSD && ${OSREL:R} >= 14 OSVERSION is more inclined towards specific stable points when something breaking might have occurred, like the introduction of openssl3 or the upgrade of llvm, which breaks things. |
devel/kyua/Makefile | ||
---|---|---|
48 | Done. Thanks for the help with the ports framework. |