> Note that I'm not a huge fan of the additional NULL checks in all the plugin
> hook functions (first commit in the series), it just makes it more noisy, and
> we could just initialize an empty rpmPlugins struct with rpmpluginsNew() in
> fsmPlugins() instead of returning NULL. But then, it's probably safer to have
> the NULL checks in place.
Hmm. I thought we wouldn't need any new NULL checks because I thought that's
what happens with --noplugins anyway, but apparently --noplugins ends up
initializing an empty rpmPlugins struct, and just falling through with that.
Adding NULL checks isn't the end of the world, just a little annoying indeed.
One observation from a closer look is that we also have various per-te plugin
hooks in psm, and those shouldn't be called on an src.rpm either. I don't think
they get called currently ... yup, because the src.rpm unpack sneaks its way
around it. It's weird that you can add src.rpm's to a transaction but then not
do anything with them there. Except okay, check dependencies, *that* is why
it's permitted.
So with all that, perhaps the easiest way is probably to temporarily replace
ts->plugins with an empty set during rpmInstallSourcePackage(). It's a bit
dirty of course, a cleaner way would be passing plugins through psm to fsm, but
that requires changing a whole lot of stuff on the way and we prefer a small
backportable patch for this.
Another possibility might be checking for src.rpm centrally from
RPMPLUGINS_SET_HOOK_FUNC, we could pass a te/NULL to it and let it "return"
NULL hookFunc for any src.rpm.
Hmm :thinking:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3470#issuecomment-2519513478
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/3470/c2519513...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
