On 02/02/16 01:58, Didier Kryn wrote:
> Le 01/02/2016 14:13, Simon Hobson a écrit :
>> 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.

very much so, on both counts. The only two alternatives are a README telling the
user to go and edit certain files before using the package ... unpopular and not
appropriate for many use cases, or introduce a centralised API that holds all
usual configurations in a database and provides standard tools to read and
modify it. This was the Microsoft registry solution, it is also the Gnome
solution. It is much more problematic in my view. And requires the kind of API
standardisation that devuan rejects.

An explicit advantage of multi files over an attempt to make a single point of
configuration via an API is the network manager in gnome. Using the GUI will
edit the files you would otherwise use for the setting. This will often undo
carefully established manual settings. These manual settings are needed even if
you prefer the GUI because the GUI only provides the way to set up commonly
needed network stuff. So if your network is uncommon you had better purge the
GUI since it will not understand or respect the weird settings you need. If you
have the dedication to GUI and the resources of a global mega-corporation it is
possible to make a similar GUI actually respect the under-lying settings ... but
it is incredibly hard work, way beyond almost any organisation. OSX did achieve
this (I do not know if they kept it though), but with unthinkable hours of
developer time I am sure, it was years of effort even for them.

>>
>>
> I fully agree that "this is a good thing". There remains one question:
>
> On my laptop the file 99synaptic contains only one line:
> APT::Install-Recommends "false";
>
> If all the files are read by all apt tools, then the setting meant for synaptic
> applies to all apt tools. If i'd purge synaptic, then the behaviour of apt-get
> might change. Does it make sense? It seems to me that this file should contain
> some indication tnat the setting applies only to synaptic.

it is in the apt configuration, it changes apt behaviour, it is in no way
limited to synaptic, it is some change that the synaptic package felt was needed
different from default settings ... I do not know synaptic but perhaps it deals
with recommended in its own way and thus needed to tell apt-get not to do it.
The name of the file indicates that this is an apt configuration added by the
synaptic package. Many packages are more polite and do include comments in their
files, where comments are allowed at that point in the .conf file of course!

Synaptic and the direct apt tools both use the same back-end, Synaptic makes the
assumption that it will replace apt-get for the user so sets apt up to suit
usage via Synaptic. It cannot really make any other assumptions, and certainly
should undo those modifications if it is removed. And the whole arrangement is a
lot!! less error prone than if it attempted to edit an apt.conf file each time.
With more effort Synaptic could perhaps leave apt settings untouched, but they
assume they are providing the new, improved GUI front end and for most of their
users that is true. It is the reason I personally prefer to avoid such GUI
interfaces.


Simon