Florian Zieboll <[email protected]> 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. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
