Page MenuHomeFreeBSD

devel/kyua: Deprecate in favor of the base version
ClosedPublic

Authored by igoro on Nov 7 2024, 11:43 AM.
Tags
Referenced Files
F107687025: D47473.diff
Fri, Jan 17, 2:09 PM
Unknown Object (File)
Wed, Jan 15, 5:38 AM
Unknown Object (File)
Mon, Jan 13, 12:27 AM
Unknown Object (File)
Thu, Dec 26, 9:33 PM
Unknown Object (File)
Wed, Dec 25, 10:15 PM
Unknown Object (File)
Tue, Dec 24, 11:23 PM
Unknown Object (File)
Dec 11 2024, 9:46 AM
Unknown Object (File)
Dec 3 2024, 6:56 PM
Subscribers
None

Details

Summary
- 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)

Diff Detail

Repository
R11 FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

igoro requested review of this revision.Nov 7 2024, 11:43 AM
igoro created this revision.

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.

Please, check the updated patch as the follow-up of your email.

Update the deprecation notice as suggested.

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.

igoro edited the summary of this revision. (Show Details)

IGNORE it for 14.0+

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.

bofh added inline comments.
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.
Although developers often try to find reasons not to mention OPSYS, be aware that there might be FreeBSD derivatives that also utilize the FreeBSD ports, and this might not be the same case for them, like DragonFlyBSD.

This revision is now accepted and ready to land.Nov 13 2024, 12:55 PM
igoro added inline comments.
devel/kyua/Makefile
48

Done. Thanks for the help with the ports framework.

This revision was automatically updated to reflect the committed changes.
igoro marked an inline comment as done.