Fix deprecated code

[m-czernek]

What does this PR do?

This PR backports saltstack/salt@67b08ab

This PR fixes runtime errors connected to warn_until_date code that's been deprecated upstream. This PR works around the code removal in saltstack/salt@67b08ab

What issues does this PR fix or reference?

Fixes: https://bugzilla.suse.com/show_bug.cgi?id=1226118

Merge requirements satisfied?

[NOTICE] Bug fixes or features added to Salt require tests.

• Docs
• Changelog - https://docs.saltproject.io/en/master/topics/development/changelog.html
• Tests written/updated

Commits signed with GPG?

Yes

Please review Salt's Contributing Guide for best practices.

See GitHub's page on GPG signing for more information about signing commits with GPG.

[agraul]

We don't use upstream's deprecation/removal policy and can't remove features in a maintenance update

[m-czernek]

@agraul I get that but the code doesn't work right now - we're including it, but if a user touches the code, it'll blow up with an exception. Isn't it the same state as right now? Would you prefer that we diverge from upstream and modify the dates?

[agraul]

From a quick look, I think we don't know if it's broken. Salt's deprecation mechanism warn_until_date raises the RuntimeError. That's a self-inflected wound, we could also move the date further out to the future. Then we don't get the RuntimeError anymore.

Salt uses this to force their developers to stick to the deprecation timeline and actually remove code once it reaches that date. For us it's annoying, this isn't the first time it has happened, because we have longer support cycles and don't want to drop features without moving to a new major version.

[m-czernek]

@agraul I take it from your response that you would prefer for us to diverge from upstream, even if the code was blowing up until now (and therefore, should be safe to remove since we had no complaints).

In such case, this should be good enough. I set the date to 2026 but we should upgrade to 3007.x before that. LMK if you'd prefer to set a different date.

Question: shall I also adjust https://github.com/openSUSE/salt/blob/openSUSE/release/3006.0/salt/modules/aptpkg.py#L3130 ? We adjusted the date to 2025, but I'm quite sure we won't update to 3007.x by Jan 1st, 2025, right?

[agraul]

@agraul I take it from your response that you would prefer for us to diverge from upstream, even if the code was blowing up until now (and therefore, should be safe to remove since we had no complaints).

Yes. When it comes to the support lifecycle, we are not following upstream. Again, we can't drop features in minor updates. I understand that this feature was broken for months, but now that we know about it, we should fix it according to our lifecycle policy.

In such case, this should be good enough. I set the date to 2026 but we should upgrade to 3007.x before that. LMK if you'd prefer to set a different date.

We won't move to the 3007 series, that's a short-term-support release from upstream. They won't support it for as long as they will support 3006 and 3008, by skipping it we can benefit from reduced backporting efforts. 2026 should be okay.

Question: shall I also adjust https://github.com/openSUSE/salt/blob/openSUSE/release/3006.0/salt/modules/aptpkg.py#L3130 ? We adjusted the date to 2025, but I'm quite sure we won't update to 3007.x by Jan 1st, 2025, right?

We should start packaging 3008 soon, but we won't replace 3006 by January, that's correct. We should either bump this date, or change warn_until_date to never raise an exception.

[m-czernek]

... now that we know about it, we should fix it according to our lifecycle policy.

Ack, makes sense.

We should either bump this date, or change warn_until_date to never raise an exception.

Personally, I'd prefer to adjust the date as that change is simpler (both to understand and to implement) than modifying the warn_until, warn_until_date, and kwargs_warn_until methods. Done in a new commit btw.