On Mon, Jun 18, 2018 at 06:10:04PM +0200, Roland Fehrenbacher wrote: > >>>>> "HG" == Helmut Grohne <hel...@subdivi.de> writes: > HG> You moved the programs and the corresponding manual pages, but > HG> the development manual pages still live in libfabric1 and are > HG> still problematic for the very same reasons. Likely those > HG> remaining manual pages should go into libfabric-dev rather than > HG> libfabric1. They're only useful for developing with libfabric > HG> and not for merely using the library. > > Amongst others, the man pages in /usr/share/man/man7 describe run-time > environment variables, hence they should be in the libfabric1 package.
I may have misunderstood the purpose of the manual page, so maybe libfabric-dev is not the solution. Still, the Debian policy section 8.2 is quite clear: | If your package contains files whose names do not change with each | change in the library shared object version, you must not put them | in the shared library package. Irrespective of what a good solution might be, I think that the manual page violates this and thus poses a release critical bug. Concerning the question where those pages could live, I still think that libfabric-dev might not be the worst choice. man 7 fabric starts out with explaining which header to include - a header that is part of libfabric-dev. Nextup I randomly picked man 7 fi_direct. That's a manual explaining a macro and going into detail that recompiling applications is necessary - a process that surely requires libfabric-dev. Again, the development package seems like a reasonable place to me. As another random example, fi_udp doesn't seem to be talking directly about the C API, but reading the manual page requires more background knowledge and is not something random users will be up to. The utility of this manual page in libfabric1 is limited at best. For closing this bug however, you should make a stronger case as to why policy section 8.2 is not violated. Helmut
