Okay so, trying to give a better idea of what I'm after:
The fact that RPMRC_PLUGIN_CONTENTS is still needed is a strong signal that
it's not quite right.
The way I'm imagining this is that you have a probe function for the content
handler, that gets called for each and every package, and for stock rpm
content, it just returns an internal function. For other content, it returns
the handler from the first plugin that claims the content type and if nothing
handles it, it's obviously an error. This should happen at the stage where the
transaction is populated, not during it.
The fsm code for handling different types doesn't differ at all, it's just a
function pointer that gets called. Ie there's no
rpmpluginsCallFsmFileArchiveReader() or rpmpluginsCallFsmFilePrepare(), these
are determined by the early probe. And so there are no
rpmteSetCustomFileInstaller() or rpmteSetCustomArchiveReader() or any
corresponding custom-call-functions either, it's always just a function pointer
to whatever is handling the content.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2057#discussioncomment-5046976
You are receiving this because you are subscribed to this thread.
Message ID:
<rpm-software-management/rpm/repo-discussions/2057/comments/5046...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
