Announcement

Collapse
No announcement yet.

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

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    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...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

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

    Code:
    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.

    Comment


    • #3
      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.

      Comment


      • #4
        Originally posted by andyprough View Post
        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.

        Comment


        • #5
          Originally posted by andyprough View Post
          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>
          Last edited by schmidtbag; 15 November 2019, 10:27 AM.

          Comment


          • #6
            Oh well, Docker is dead anyway.

            Comment


            • #7
              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.

              Comment


              • #8
                It's important to mention the ubuntu article isn't talking about their base ubuntu images you'd typically be using to create your own images from, but the images they themselves build for their own app deployments.

                Comment


                • #9
                  Originally posted by schmidtbag View Post
                  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.
                  You are right, I should have read the Ubuntu blog post before I wrote that - this was not about disabling recommended packages by default, this was about doing it as an option to reduce container size.

                  Comment


                  • #10
                    Originally posted by DoMiNeLa10 View Post
                    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.
                    Don't know about containers (don't use that at all) but DEB have far better support for various init-systems than RPM, if you have to support sysvinit, upstart and systemd for the same package it's breeze with DEB but not so much on RPM (talking from experience here).

                    Comment

                    Working...
                    X