Bálint Réczey <bal...@balintreczey.hu> writes: > On 2025. Jan 16., Thu at 8:17, Simon Richter <s...@debian.org> wrote:
>> Agreed, it's not a complete fix, but I'd expect the frequency of >> changes in the output besides the version number to be low enough for >> this to be the least-effort solution. >> If it means we need to trigger a rebuild of a few packages every few >> years, then this thread has already used more time. > I agree. It is very easy to detect file differences between multiarch > packages and scheduling binNMUs. > Since the described problem potentially affects all packages shipping > man pages with the binaries - which is the best practice - splitting man > pages from a single package to solve that particular problem sounds > misdirected effort. Hm, I would say that the energy put into finding workarounds for varying content in multiarch packages and scheduling binNMUs would be the more wasted effort in the long run. I would advise every multiarch package shipping man pages to move them into a separate package, which is a one-time fix that makes the problem go away for that package. To me, this is an extension of the long-standing advice that every shared library should be isolated in its own package and not include other files. It's for a somewhat similar reason, too: for shared libraries, this is to avoid conflicts on SONAME bumps, and in this case, it's to avoid conflicts on binNMUs. There has never been a best-practice requirement that the man pages be in the same binary package, only that they be installed when the package is installed, so putting them in a dependency has always been fine. I think the concern here may just be that the effective dependency on libpam-doc is Suggests and people would rather it be something stronger. That's an argument for putting them in libpam-runtime, even though it's not a perfect semantic fit, because that package is Priority: required. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
