Pulling rpmts into the picture seems wrong to me, it limits the opportunities
for using such a thing quite a lot. For example the build code doesn't have a
transaction set around generally, and it'd seem weird to stick one in there for
this thing's sake.
You'll want to hook it into rpmlog itself somehow. The simplest option would be
just a global thing you can reset with an API call, a more flexible one would
be returning a handle to both the log context and the set, and then call
through that.
Something like (dunno about the names, but just to give you an idea)
- rpmlogOnce logctx = rpmlogOnceNew();
- rpmlogOnce(logctx, const char * key, int code, const char * fmt, ...)
- rpmlogOnceFree(logctx)
...and then hook that into rpmts for the effect in this particular case. The
downside is that then you need to hang these context into here and there to
have it available where you need it. So I'd just settle for a global thing
inside rpmlog that you can reset at eg end of transactions and builds.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3389#issuecomment-2419670110
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/3389/c2419670...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
