Quiet and unattended installation with apt-get (2015) | Hacker News Reader

Quiet and unattended installation with apt-get (2015)

peteris.rocks

21 pointstimxor9 comments

This will still fail if a package upgrade prompts for a change to a configuration file. You can force it to keep existing files and therefore not ask. The command I use is:

DEBIAN_FRONTEND=noninteractive apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" install blah wibble

(This also works for "upgrade" as well as "install".)

I would argue that you want new package installations to be verbose.

But most people could stand to have package upgrades handled quietly.

apt install apticron

can do that for you. Options include "download upgraded packages and tell me in mail", or "download and install upgraded packages and tell me in mail".

For upgrades, I just configure unattended updates and call it good.

For installation verbosity, I think it really depends on your use case. On a user system like a laptop, sure; interactive + high verbosity is good. On a server, less so, and in a container, I would be quite happy with no output except an exit code. (This is one of many reasons that I like Alpine Linux for containers; apk defaults to installing with no interaction required.)

Unattended package installation without needing the sudo password? Where do I sign up? /s

The topic of undocumented flags is an interesting one (passing flags to dpkg from apt). Wish they had explained how that one was found out.

My experience with apt-get makes me so wary of package management as a whole that I'm finding myself afraid of winget. Centralized package management never appealed to me and package managers have been nothing but problems (broken state, incompatible mismatches of shared libraries, one installation at a time only, etc) for whatever marginal benefit (disk space is a lot cheaper than it was in the 90s and programs updating their own libraries works just fine, and you can always drop in a new dll yourself if it's so important)

I have also had painful experiences with broken APT state being quite difficult to recover from.

But if you leave it up to developers of each program to update all their own dependencies, it just won't happen. Old versions of libraries (possibly with CVE) would stick around in the wild a lot longer this way.

Interesting, I have had the exact opposite experience. apt-get is the overwhleming reason I stick with Debian.

I have only seen such behavior you describe when I did a franken Debian [1] or added unofficial repositories (which I would argue is like installing random programs on any computer, do at your own risk). Even then, it only broke when I did a major upgrade (For comparision, it would be like upgrading from Windows 7 to 10). When I stick with official repositories or I understand what I am doing with unoffficial repositories, I have never had an issue.

The one installation of a time is curious too, as I have installed lots of programs at the same time with apt-get without issue.

[1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank...

Package managers assume they own the entire system. When you use something like Debian, which tends to have older versions of things, and want to run something that wants a newer version of something fundamental like libc, you can run into problems.

> whatever marginal benefit

Saving developer time and factoring code multiple programs use into a library is probably more than a marginal benefit.

> programs updating their own libraries works just fine

Until you have a security vulnerability in something like openssl, the package management system lets you patch this vulnerability for many programs at once. You then have things like resolver and socket libraries which you probably tend to want consistent across your system.

> you can always drop in a new dll yourself if it's so important

It should probably be easier to override a library version locally in case you do need to do that. That probably gets into security issues, as if anything can modify library versions, it also lets malicious software hook into those libraries.

> My experience with apt-get makes me so wary of package management as a whole that I'm finding myself afraid of winget.

They're very different programs solving mostly different problems. Has your experience with Internet Explorer so turned you off to the idea of a web browser that you'd refuse to use Chrome or Firefox?

> Centralized package management never appealed to me and package managers have been nothing but problems (broken state, incompatible mismatches of shared libraries, one installation at a time only, etc) for whatever marginal benefit (disk space is a lot cheaper than it was in the 90s and programs updating their own libraries works just fine

The primary benefit I've always seen has nothing to do with disk space and everything to do with management. I can run a single command and have my entire system up-to-date, from kernel to applications (and I can do this without every single application running a persistent background process), and install any supported package from a trusted repository with equally little effort.

> you can always drop in a new dll yourself if it's so important

Windows allowing this remains a massive security hole. It would be better if they only allowed it in folders that were read-only to unprivileged users, but I'm not aware that they ever added any restrictions. On Unix at least the person running the program has to override ld's path.

Reply on news.ycombinator.com