Filter Lua deprecation warnings based on the originating rpm version #3270
Conversation
|
Anti social or not, the reason for these warning is that those packages won't work with the next RPM version. Not sure if keeping the users in the dark will do them any favors. Right now they can demand the vendor to fix their packages before it is too late. |
|
I said this someplace else too, but: the thing is, I don't think we can actually proceed with the removal of these functions as originally planned. This stuff is used by very few packages but those very few happen to be corner stones of distros, and if we just remove the functions we make eg all current Fedora and RHEL versions uninstallable. That's just not acceptable really. We can probably remove them in rpm 7... |
|
if we don't actually remove the functions this is fine. We just need to issue the warnings in the last RPM version before removing them. |
|
No, the point is that we need to warn on all new usages of these functions to scare people away from using them. Otherwise, we'll be in the same situation ten years from now and still can't remove those functions. |
|
OK, I could have worded that better. Yes, we need to issue a warning for all new usages. We will need to issue a warning to all usages the release before we actually remove the functions - with the hope that old usage has died out til then. |
|
Right, that I can agree with: we need to turn the warnings back to the always warning mode before actually removing them, probably more than one release in advance. |
|
Hmm, probably there should be a switch to enable all deprecation warnings regardless of versions so it's possible to test whether you're affected or not. Maybe not necessary for the first version, but going forward. |
|
Oh and to elaborate on the "poor mans symbol versioning" comment: what we could and probably should do is literally prevent the use of these functions in v6 packages. We now have (the beginnings of) means to track that. |
These fellas have enough arguments as it is, it's moderately hysterical they don't actually accept the main struct as an argument. No functional changes.
pmatilai
requested review from
dmnks and
ffesti
and removed request for
a team and
dmnks
Issuing deprecation warnings on packages built long time ago is just antisocial behavior when the user is powerless to do anything about it. When running scripts, pass the builder rpm version to Lua through the registry, and filter out the warnings when the package was built with an rpm version where these functions were not yet deprecated. Usage through rpmlua and macros always gets warnings: those are things that can technically be fixed by the user.
|
Tests added, this is basically the MVP version that would be targeted at 4.20 backporting. |
Issuing deprecation warnings on packages built long time ago is just antisocial behavior when the user is powerless to do anything about it.
When running scripts, pass the builder rpm version to Lua through the registry, and filter out the warnings when the package was built with an rpm version where these functions were not yet deprecated.
Usage through rpmlua and macros always gets warnings: those are things that can technically be fixed by the user.
The first commit is prerequisite refactoring to make this possible.
Thoughts? This could be considered the beginnings of poor mans symbol versioning for rpm embedded Lua.
Tests would need to be added of course.