Canonical Finally Discovers "--no-install-recommends" Is Worthwhile For Docker

I seriously doubt anyone outside of Cannonical uses Debian or Ubuntu containers for anything. These distros are a mess of compatibility layers for legacy init systems, a crappy network manager, and a bad package manager. These distros might be ok for brain dead desktop users, and that's about it.

[Britoid]

Oh well, Docker is dead anyway.

[schmidtbag]

You're going to have a lot of clueless users with no idea how to figure out what recommended software their docker image is missing or how to add it to get the functions they need. It's a tradeoff.

Recommended packages are enabled by default. If you choose to disable them, either you know what you're doing or it's your own fault if you get lost.

<rant>
Personally, I don't like the usage of "recommended" or "suggested" packages at all. I prefer dependencies be "absolute", and then use meta-packages for varying degrees of recommendation or hand-holding. Sometimes those are actually used. Take for example in Debian, you get "kde-baseapps", "kde-full", and "kde-standard". They all install chunks of KDE, but to varying degrees. Oddly enough, kde-full has recommended and suggested packages... Seems a bit counter-intuitive.

So to me, those dependency attributes should be replaced with "*-recommended" and "*-suggested" metapackages. If you find you don't want something and the package manager complains that the metapackage depends on it, just remove the metapackage. Even now, nothing depends on metapackages (except for maybe meta-metapackages) so they're totally safe to remove after they fulfill their purpose.
</rant>

[FlawlessVolcano]

You're going to have a lot of clueless users with no idea how to figure out what recommended software their docker image is missing or how to add it to get the functions they need. It's a tradeoff.

This is the problem with trying to hold everyone's hand and package everything for them in bundles. You're going to guess wrong about their use cases some of the time, and leave them in a state of complete ignorance about how to rectify it.

I saw the same with the KDE flatpaks for their Okular PDF app. KDE hasn't figured out how to integrate printing within the Flatpak sandbox, so they just released the Okular flatpak with no ability to print. Printing isn't vital to the viewing or editing of the PDF's, but about 20% of the time someone is going to need to print something. And not only didn't KDE include it, they don't even give any data about why the print function is broken. The print dialog box still comes up, but you can't select a printer, so the user is going to think there is something wrong with their printer or their CUPS setup or something. If you dig deeply enough into the bowels of KDE's bug reporting, you find that they admit they don't have the ability to print from the flatpak sandbox yet, and haven't figured out how to implement it. But 90% of users are going to be completely clueless as to the problem, and think that it must be something wrong with the rest of their system.

While broken printing in qt apps in flatpak is true I don't see how it's related to docker size/usability tradeoff. Unlike docker situation where user can install additional packages themselves there is no switch to make printing work for qt apps and users can't do anything about it.

[andyprough]

You're going to have a lot of clueless users with no idea how to figure out what recommended software their docker image is missing or how to add it to get the functions they need. It's a tradeoff.

This is the problem with trying to hold everyone's hand and package everything for them in bundles. You're going to guess wrong about their use cases some of the time, and leave them in a state of complete ignorance about how to rectify it.

I saw the same with the KDE flatpaks for their Okular PDF app. KDE hasn't figured out how to integrate printing within the Flatpak sandbox, so they just released the Okular flatpak with no ability to print. Printing isn't vital to the viewing or editing of the PDF's, but about 20% of the time someone is going to need to print something. And not only didn't KDE include it, they don't even give any data about why the print function is broken. The print dialog box still comes up, but you can't select a printer, so the user is going to think there is something wrong with their printer or their CUPS setup or something. If you dig deeply enough into the bowels of KDE's bug reporting, you find that they admit they don't have the ability to print from the flatpak sandbox yet, and haven't figured out how to implement it. But 90% of users are going to be completely clueless as to the problem, and think that it must be something wrong with the rest of their system.

[barti_ddu]

The first thing I do on a freshly installed Debian system is:

echo 'APT::Install-Recommends "false";' > /etc/apt/apt.conf.d/99-custom

I don't find it extremely difficult to install some of the recommended dependencies after reading package description later by hand.

[phoronix]

Phoronix: Canonical Finally Discovers "--no-install-recommends" Is Worthwhile For Docker

Debian's APT package manager has supported the --no-install-recommends for years so only the main dependencies are installed and not the "recommended" packages. Seemingly it's taken Canonical until now to figure out how practical that option is for reducing the size of their Docker containers...

http://www.phoronix.com/scan.php?page=news_item&px=Canonical-Docker-NIR