> recs is not really suited for this. It is a vector so lookups are not cheap.
> It only stores WARNING and above. We might want to link to the recs entry but
> even that does not really solve anything if the lower prio entries are
> missing.
Sure, the logic for populating `recs` would have to be adjusted, my point is
that message de-duplication can also be thought of as filtering, and we already
do by-mask filtering in `rpmlogPrintByMask()`.
What I'm getting at is that we could just record all the messages and only
decide how to collapse (de-duplicate) them into a single meaningful message
after the fact, perhaps even using the information in those messages somehow.
Yes, we need to do that on-the-fly as well, of course, but that would just be a
special case of that.
That said, I haven't thought this through too much, it's just my gut feeling
speaking :smile: Having this specialized `seen` map also works and we can
always refactor it in the future, it's not a big deal.
> The additional string is there for cases where the message contains differing
> info. E.g. the package name or location of the error. Imagine suppressing a
> missing macro message. This will give a file and line number. And you do want
> that so you can look at the place where things go wrong in case it is just a
> typo. You still want to suppress the follow up messages if the macro is
> actually missing. So having a key allows to put them all under the same
> category.
Indeed. I had this in the back of my mind too, just needed to see it written
down for it to click. Thanks!
> I don't think we will have logging objects for every possible occasion but
> only for majors things like builds or transactions. So I expect the domain to
> stay relevant even if we no longer have global logging. But that might just
> me being unimaginative.
Right, it's just that "context" coincides with "domain" in a way, but we
already use the term "context" for a different purpose in the logging module,
so yep.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3417#issuecomment-2449336976
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/3417/c2449336...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
