Bug#891395: closed by Roland Fehrenbacher <rfehren@debian.org> (Bug#891395: fixed in libfabric 1.6.1-1)
On Mon, Jun 18, 2018 at 06:10:04PM +0200, Roland Fehrenbacher wrote:
> >>>>> "HG" == Helmut Grohne <helmut@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
Reply to: