[BPO] man-db/2.10.2-1 from jammy

Backported debs in: https://launchpad.net/~jrodrigu/+archive/ubuntu/bpo/+packages

From what I read (and remember), the command doesn't freeze but just takes
a bit long.

Honestly I don't really consider such issue worth a backport, and it's not
really bringing any new feature to the table (at least, you are not
describing anything).

I was thinking that perhaps this could be done as part of an SRU, but the
relevant patch is just huge, so probably not either...

Other BPO team members: what do you think?

On Fri, 7 Oct 2022, 6:10 pm Jorge Rodríguez, <email address hidden>
wrote:

> Backported debs in:
> https://launchpad.net/~jrodrigu/+archive/ubuntu/bpo/+packages
>
> --
> You received this bug notification because you are a member of Ubuntu
> Backporters, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1992163
>
> Title:
> [BPO] man-db/2.10.2-1 from jammy
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/man-db/+bug/1992163/+subscriptions
>
>
> --
> ubuntu-backports mailing list
> <email address hidden>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
>

Is there a reason the fixes can't be cherrypicked and then SRU'd to fix this issue? Backports is typically NOT the way to get fixes for issues into already stable releases.

@teward: look at https://gitlab.com/cjwatson/man-db/-/merge_requests/2/diffs - it's quite the big change to defend for a SRU. or, rather, quite deep into the code.

Mattia: Big change or not, SRU team might let it through because it's a *performance bug fix*. This alone is not sufficient, in my opinion, for a backport, when an SRU is the process it should be going through because it fixes a bug - a performance one, granted, but it's still SRUable I believe.

As the upstream maintainer, my advice when asked has been that attempting to cherry-pick this particular set of fixes for an SRU would be very difficult to get right. I think it's likely that the GitLab merge request linked above depends on a number of other preparatory commits. I'm not going to stop people trying, but I think it would be difficult for somebody unfamiliar with the code.

It's been a while since I was involved in this, but when I was last on the team that reviewed SRUs I don't think I'd have let pure performance fixes through unless they were very trivial and obvious.

We have discussed this in the last Backporters meeting, and we decided not to accept this, as a simple performance bug, which is not what the backport pocket is intended for (that's more about new features).