Florian Zieboll <f.zieboll@???> wrote:

> For the fun of it, I just ran an "apt-get install --install-recommends
> --no-install-recommends" and it chose to not install the recommends.
> The same with contradicting lines in apt.conf(.d/*):
>
> APT::Install-Recommends "0";
> APT::Install-Recommends "1";
>
> This will install the recommends, the other way around it won't.
> Apparently there's still some behavior left in modern Linux that is
> coherent with an autistic mindset, hahaha.

Makes sense to me too - first entry sets/resets option, next entry resets/sets the same option - the last one taking effect.

> As with any of these newish "*.d/" folders, you can just
>
> $ cat apt.conf.d/* > apt.conf && rm -r apt.conf.d/
>
> without any consequences regarding the configuration. AFAIU this is all
> about easier deployment (and automated removal) of configurations - like
> hitting some button on a shady website to add distribution independent
> repositories to the sources.list.

More to the point, it means (in the general case) a number of packages can add/remove their own configs during package install/upgrade/removal just by adding/updating/removing "it's" config file from the conf.d directory. For another example, when installing Xen, it adds a file to Grub's conf.d to add the Xen boot options. Same with various web packages that put a file in /etc/apache2/conf.d.

IMO it's far better than trying to come up with some mechanism to *SAFELY* edit a shared config file.

It also means the user/admin can add their own config file, and if they name it to sort last then they can override any other default settings - but without impacting on the ability of a package to update it's own file. Once you get into editing the package supplied config file then upgrading gets a bit less automatic.

So overall I think this is "a good thing" - even though it does have one or two downsides.