openssh-client could suggest xauth rather than recommend it

Proposed debdiff

I also downgraded the recommend to a suggestion in openssh-server, to avoid pulling X libraries in the server case too.

I'm not so sure that dropping it to a suggestion is a good idea. A lot server software are managed by a GUI, which you need to run remote.

Note that dropping it to a "Suggests" doesn't prevent it from being installed by other packages. If you install a GUI on the server then xauth should get installed as a dependency of the X server.

The goal is to mimic what was done in hardy, where recommends were not installed by default : the minimal and standard seeds then did not contain any X libraries.

http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.hardy/minimal
http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.hardy/standard

Contrast that with the now-heavier minimal and standard seeds in intrepid:

http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/minimal
http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/standard

Please compare bug 51774. I'm not going to play piggy-in-the-middle here; I think Recommends is a decent compromise between "X is evil, we must not see any X packages at all in our lists" and "we'd like ssh X forwarding to work out of the box".

Bug 51774 is about silent-failure behavior when forwarding X11 without xauth(1) on the remote side, which is a separate issue. Colin, you yourself said that a package dependency doesn't address that, and I agree.

I also agree with Thierry's premise that those X11-related packages should not be pulled in by openssh-client, and would go further to say that they have no place in an out-of-the-box CLI install. (I filed bug 293313 before fully understanding what was going on.)

I'd like to see xauth downgraded to Suggests: in both the client and the server. It's silly for either of them to pull in x11-common et al. unless explicitly told otherwise via --no-install-recommends, and in any event we're talking about a behavior that didn't even exist before the change to apt earlier this year. More people are still accustomed to installing xauth/xorg explicitly if they need it, than to relying on the Recommends: to do it for them; we're not going to see hordes of hapless users running around because they can't forward X11 connections anymore.

When apt was changed to install Recommends: by default, Michael Vogt said, "We should also clean up recommends were appropriate and downgrade them to suggests and sent the patches [to] debian." I think this is a case where that is needed.

If the downgrade on -client and -server is too much, then at least do it for -client. Systems with xorg will already have xauth, so the only case left is systems without X11 serving as an intermediate SSH hop between systems that do (and does *that* rare case warrant polluting minimal CLI installs with X11 libs?).

This is still an issue with xenial.

The problem this causes is that on an Ubuntu Server system, installing any package which depends on openssh-client will also pull in pretty much the whole X11 system. Example:

root@xenial1:~# apt-get install rancid
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  expect fontconfig-config fonts-dejavu-core libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2
  libdrm-radeon1 libfontconfig1 libfontenc1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libice6
  libllvm3.8 libpciaccess0 libperl4-corelibs-perl libsm6 libtcl8.6 libtk8.6 libtxc-dxtn-s2tc0
  libx11-xcb1 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-shape0
  libxcb-sync1 libxcomposite1 libxdamage1 libxfixes3 libxft2 libxi6 libxinerama1 libxmu6 libxpm4
  libxrandr2 libxrender1 libxshmfence1 libxss1 libxt6 libxtst6 libxv1 libxxf86dga1 libxxf86vm1
  tcl-expect tcl8.6 tk8.6 x11-common x11-utils xbitmaps xterm
Suggested packages:
  diffstat tcl-tclreadline mesa-utils xfonts-cyrillic
The following NEW packages will be installed
  expect fontconfig-config fonts-dejavu-core libdrm-amdgpu1 libdrm-intel1 libdrm-nouveau2
  libdrm-radeon1 libfontconfig1 libfontenc1 libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libice6
  libllvm3.8 libpciaccess0 libperl4-corelibs-perl libsm6 libtcl8.6 libtk8.6 libtxc-dxtn-s2tc0
  libx11-xcb1 libxaw7 libxcb-dri2-0 libxcb-dri3-0 libxcb-glx0 libxcb-present0 libxcb-shape0
  libxcb-sync1 libxcomposite1 libxdamage1 libxfixes3 libxft2 libxi6 libxinerama1 libxmu6 libxpm4
  libxrandr2 libxrender1 libxshmfence1 libxss1 libxt6 libxtst6 libxv1 libxxf86dga1 libxxf86vm1
  rancid tcl-expect tcl8.6 tk8.6 x11-common x11-utils xbitmaps xterm
0 to upgrade, 53 to newly install, 0 to remove and 0 not to upgrade.
Need to get 20.1 MB of archives.
After this operation, 172 MB of additional disk space will be used.
Do you want to continue? [Y/n] n

This is silly. But:

root@xenial1:~# apt-get install rancid --no-install-recommends
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
  expect libperl4-corelibs-perl libtcl8.6 tcl-expect
Suggested packages:
  tcl8.6 diffstat
Recommended packages:
  tcl8.6 tk8.6
The following NEW packages will be installed
  expect libperl4-corelibs-perl libtcl8.6 rancid tcl-expect

That's what I expected.

It seems to me that:

* if the system you are using a client is graphical (e.g. Ubuntu desktop), then you will probably have xauth already

* if the system you are using is text-based, then you definitely don't want xauth/X11 just to have an ssh client.

So if anything "recommends" xauth, shouldn't it be X11 or the desktop environment, not the openssh client?

Wow this is an old issue (and still true as of artful) :-/
Maybe that really would be better off as a suggests.
In a graphical environment as suggested before it is around via the dep from xorg and others.

But other than feeling embarrased that this is around for so long I think this is nothing that should be changed in Ubuntu individually. That we should do in sync with Debian.

Therefore if anybody still (or newly re-en-kindled) cares it would be great to file that with Debian and we pick it up from there. Also IIRC cjwatson takes care of it in Ubuntu AND Debian so he certainly has more experience to decide on this.