Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add rpmtsLogOnce() #3389

Closed
wants to merge 1 commit into from
Closed

Conversation

ffesti
Copy link
Contributor

@ffesti ffesti commented Oct 17, 2024

Allows showing a log message only once.

Use in handleHdrVS. This does not add a new test case but various existing test cases fail when the NOKEY message is omited or shown more than once.

Resolves: #3336
Resolves: #3333

Allows showing a log message only once.

Use in handleHdrVS. This does not add a new test case but various
existing test cases fail when the NOKEY message is omited or shown
more than once.

Resolves: rpm-software-management#3336
Resolves: rpm-software-management#3333
@ffesti ffesti requested a review from a team as a code owner October 17, 2024 12:05
@ffesti ffesti requested review from pmatilai and removed request for a team October 17, 2024 12:05
@pmatilai
Copy link
Member

pmatilai commented Oct 17, 2024

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 and remember to specifically call through that. So I'd just settle for a global thing inside rpmlog that you can reset at eg end of transactions and builds.

@ffesti
Copy link
Contributor Author

ffesti commented Oct 18, 2024

Closing until the details are figured out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants