No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by starshipeleven View Post
    You are talking of decent projects made by half-serious people.

    A lot of custom commercial stuff is using Ubuntu because that's the only non-Windows OS the developer knows, and the only OS the application will ever work on as there is no real dependency list on the payload application but it relies on "what libraries are installed by default".

    Then again, many I know would like to kill that with fire.
    That checks out if your developer team has down's syndrome.


    • #22
      Originally posted by Britoid View Post

      What does a package format have to do with an init system? RPM doesn't give a flying crap what init system is being used. RPMs however can pull their upstream service files, where as DEBs Debian has to go through and make Debian-specific service files cause of "init-freedom", whatever the fuck that means.
      Because if you package a deamon that needs to start with init then you have to supply said script in the package. In DEB you simply put debian/name.service for systemd debian/name.upstart for upstart and debian/name.init and then in the rules for the DEB build you simply put "dh_installinit" and when you execute debuild it will create .deb packages that will automatically install the correct script and perform the various different ways that are needed to install it as a service.

      For RPM:s you have to manually perform each and every step for each and every different init, e.g for systemd you have to sprinkle %systemd_preun and %systemd_postun_with_restart macros with the added drawaback that said macros only exist if you build on a system that runs that particular init so you cannot easily build a upstart package on a system that only have sysvinit and so on.

      Now this does not bother the distributions since they always create individual packages for each and every version of the distribution that they maintain but I that create 3d party applications and that have to build for several systems at once have to maintain several .spec scripts for RPM:s just to make it work while I can use a single DEB setup regardless of for which debian bases distribution or version that I'm building for.


      • #23
        Originally posted by stormcrow View Post

        Red Hat's RPM team: Challenge accepted. Hold my beer...
        They held that beer a long time ago since rpmbuild already contains init-specific macros so this is just comments from people that have never packaged a system daemon for either system as an external 3d party maintainer....


        • #24
          Originally posted by DoMiNeLa10 View Post

          From my experience most are based off alpine, and I've heard devops complain about every piece of software that requires glibc.
          Alpine stopped being a thing a year ago or so. One of the broken wheel bandwagons. The company I work for has hundreds of distinct docker images (projects) since their whole archutecture forces docker for any service. They went debian -> alpine -> debian again with some centos fringe ones.


          • #25
            Originally posted by anarki2 View Post

            Which is cool on your own hobby PC, but not when you have to deploy dozens of workstations, where manually installing tons of random missing packages isn't exactly feasible. That extra disk space is usually way cheaper than IT labor.
            This is not about the disk space: I prefer not to have any extra services/components on a server "just in case". To be fair: I'm never dealing with someone's linux desktops.


            • #26
              Originally posted by Britoid View Post
              Oh well, Docker is dead anyway.
              Yeah, Docker is quite alive and quite well. Where is this coming from?


              • #27
                Originally posted by computerquip View Post

                Yeah, Docker is quite alive and quite well. Where is this coming from?
                Possibly the fact that just last week, Docker announced they were selling their "enterprise" product to another company... and since that's assumed to be their major source of revenue, it raises all those questions about health of the business. Over a longer period, there's also some feeling that they've lost their edge a bit, with Kubernetes having taken a lot of the space that Docker were obviously trying to expand into.