Dear Maintainer,

In #1054460 a duplicate-file conflict on the podman-compose.1 manual was
resolved: the manual was dropped from the podman binary package and the
version from podman-compose was retained.

However, invoking the default podman 5.2.1 'compose' subcommand produces
output referring the user to configuration settings only found in the libpod
documentation:

  $ podman compose help
  >>>> Executing external compose provider "/usr/bin/podman-compose". Please see podman-compose(1) for how to disable this message. <<<<
  ...

This tripped me up recently: running 'man -s 1 podman-compose' opened a manual
that seemed to be the one instructed, but that didn't describe the relevant
compose_warning_logs setting to disable the message.

I'd like to request that we ship the upstream libpod manual[1] instead, and
optionally that we could retain the podman-compose version of the manual in
section 7 (misc).  Most installers of podman-compose would be provided with the
libpod manual thanks to the Recommends dependency that podman-compose has on
libpod.

Thanks!
James

[1] - https://github.com/containers/podman/blob/d0582c9e1e6c80cc08c3f042b91993c853ddcbc6/docs/source/markdown/podman-compose.1.md.in#L16

Control: reassign -1 podman-compose
Control: affects -1 = src:libpod

I actually agree with this, and was also bitten by it recently! It's
worth noting that podman-compose upstream does not ship a manpage at all
-- this is a Debian modification and divergence from upstream.

For podman to ship this manpage again, podman-compose needs to stop
shipping it, so reassigning the bug to the podman-compose source
package.

Athos & other podman-compose contributors, what do you think?

Thanks!
Faidon

From an user's point of view, I'd rather have them the other way around.
Upstream podman manual is just a manual telling users its subcommand
does nothing but forwarding the command to an external composer (with a
given precedence), and instructing on how to disable the warning.
Debian's manual page for podman-compose itself should be more meaningful
as a "Executable programs or shell commands" (section 1) manual page.
(Although it is currently only a help2man generated page.) Also, this
makes more convenient for users, since section 1 has precedence by
default over section 7.

Doing so would require shipping it as a section 7 manpage, and patching
podman source to make messages consistent. I'm afraid upstreaming this
might not make sense, though, as podman-compose does not want to
maintain a manual page yet [1]; thus no conflict actually exists
upstream (yet).

Well, this should be way more work to do, though. It would also mean
taking care of yet another patch in podman package. It is understandable
if it is chosen not to.

[1] https://github.com/containers/podman-compose/pull/481

I'm not a podman-compose contributor myself, but I hope you find my
comments useful.

Best regards,

Henrique F. Simoes