docker image ls: No header in no container

[junaruga]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

I am not sure if it is bug or intended.

Description

There is a different behavior between podman and docker-ce about the image ls command.
The difference "no header in no container" makes me wonder if the podman works

Steps to reproduce the issue:

My environment: Fedora 29.

$ which docker
/usr/bin/docker

$ rpm -qf /usr/bin/docker
docker-ce-cli-18.09.4-3.fc29.x86_64

$ rpm -q podman
podman-1.1.2-1.git0ad9b6b.fc29.x86_64

docker-ce

Remove all the container.

$ docker system prune -a -f

A header is shown in no container.

$ docker image ls -a
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

podman

Remove all the container.

$ podman system prune -a -f

A header is NOT shown in no container.

$ podman image ls -a

$ echo $?
0

When the container exists, the header is shown.

$ podman run --rm -t busybox uname -a

$ podman image ls -a
REPOSITORY                  TAG      IMAGE ID       CREATED      SIZE
docker.io/library/busybox   latest   af2f74c517aa   6 days ago   1.42 MB

Describe the results you received:

$ podman image ls -a
<= No header

Describe the results you expected:

$ podman image ls -a
REPOSITORY                  TAG      IMAGE ID       CREATED      SIZE

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

$ podman version
Version:            1.1.2
RemoteAPI Version:  1
Go Version:         go1.11.5
Git Commit:         a95a49d3038462d033f84ac314ec8a3064a99cff
Built:              Tue Mar  5 19:10:31 2019
OS/Arch:            linux/amd64

Output of podman info --debug:

$ podman info --debug
debug:
  compiler: gc
  git commit: a95a49d3038462d033f84ac314ec8a3064a99cff
  go version: go1.11.5
  podman version: 1.1.2
host:
  BuildahVersion: 1.7.1
  Conmon:
    package: podman-1.1.2-1.git0ad9b6b.fc29.x86_64
    path: /usr/libexec/podman/conmon
    version: 'conmon version 1.12.0-dev, commit: a95a49d3038462d033f84ac314ec8a3064a99cff'
  Distribution:
    distribution: fedora
    version: "29"
  MemFree: 1824788480
  MemTotal: 8030040064
  OCIRuntime:
    package: containerd.io-1.2.5-3.1.fc29.x86_64
    path: /usr/sbin/runc
    version: |-
      runc version 1.0.0-rc6+dev
      commit: 2b18fe1d885ee5083ef9f0838fee39b62d653e30
      spec: 1.0.1-dev
  SwapFree: 7979311104
  SwapTotal: 8053059584
  arch: amd64
  cpus: 4
  hostname: unused-4-164.brq.redhat.com
  kernel: 5.0.5-200.fc29.x86_64
  os: linux
  rootless: true
  uptime: 154h 33m 40.45s (Approximately 6.42 days)
insecure registries:
  registries: []
registries:
  registries:
  - docker.io
  - registry.fedoraproject.org
  - quay.io
  - registry.access.redhat.com
  - registry.centos.org
store:
  ConfigFile: /home/jaruga/.config/containers/storage.conf
  ContainerStore:
    number: 0
  GraphDriverName: overlay
  GraphOptions:
  - overlay.mount_program=/usr/bin/fuse-overlayfs
  GraphRoot: /home/jaruga/.local/share/containers/storage
  GraphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  ImageStore:
    number: 1
  RunRoot: /run/user/28707
  VolumePath: /home/jaruga/.local/share/containers/storage/volumes

Additional environment details (AWS, VirtualBox, physical, etc.):

physical.

[mheon]

I think I know where we introduced this one

[junaruga]

Thanks, libpod team.
I conformed this issue was fixed on the podman latest version on Fedora 30!

$ rpm -q podman
podman-1.3.1-1.git7210727.fc30.x86_64

$ podman image ls -a
REPOSITORY   TAG   IMAGE ID   CREATED   SIZE

$ podman images
REPOSITORY   TAG   IMAGE ID   CREATED   SIZE