On 02/05/2023 00:56, Scott Kitterman wrote:
> On Monday, May 1, 2023 3:20:19 PM EDT Einhard Leichtfuß wrote:
>> On 01/05/2023 19:47, Scott Kitterman wrote:
>>> On Monday, May 1, 2023 1:01:17 PM EDT Einhard Leichtfuß wrote:
>>>> On 01/05/2023 18:14, Scott Kitterman wrote:
>>>>> On Monday, May 1, 2023 11:06:07 AM EDT Einhard Leichtfuß wrote:
>>>>>> Package: postfix
>>>
>>> ...
>>>
>>>>>> In `main.cf`, the following lines were appended:
>>>>>>> readme_directory = /usr/share/doc/postfix
>>>>>>> html_directory = /usr/share/doc/postfix/html
>>>>>>
>>>>>> If I understand the postinst script correctly, this modification of
>>>>>> `main.cf` should only have happened upon first installation, which this
>>>>>> was not.  I was unable to reproduce this.  So maybe this modification
>>>>>> was indeed done earlier.
>>>>>>
>>>>>> However, even upon initial installation (with pre-existing
>>>>>> configuration), this should, in my opinion, not happen.
>>>
>>> ...
>>>
>>>>> Also, note that the message about is about main.cf not being modified.
>>>>> These changes are in master.cf, so I don't understand the concern with
>>>>> the message?
>>>>
>>>> The second modification (readme_directory, html_directory) was to
>>>> `main.cf`.  While this modification should only happen for initial
>>>> installations (with pre-existing configuration), the message is
>>>> displayed even then.
>>>>
>>>> Steps to reproduce (assuming postfix is not installed):
>>>>
>>>> $ apt install postfix-doc
>>>> $ echo > /etc/postfix/main.cf
>>>> $ apt install postfix
>>>
>>> To focus in on the main.cf part of this, I believe that's per policy.
>>>
>>> First, it's a change made by postfix-doc, not postifx, so the postfix
>>> package statement that main.cf was not modified by it is correct and
>>> unrelated to the main.cf change.
>>
>> Ah, I did not check the postfix-doc postinst script.  It seems that both
>> postfix-doc's and postfix's postinst scripts conditionally run
>>
>>   postconf -e readme_directory=/usr/share/doc/postfix
>> html_directory=/usr/share/doc/postfix/html
>>
>> However, postfix's postinst script only does so in the arguably rare
>> case that postfix-doc was installed first.  So one might argue that this
>> is still an action performed for postfix-doc falling under Policy 10.7.4.
>>
>>> For the postfix-doc change to main.cf, Policy 10.7.4 is the relevant
>>> portion. Postfix-doc uses the provided interface (postfconf), when
>>> available.
>> It is not clear to me that Policy 10.7.4 overrides Policy 10.7.3 w.r.t.
>> the requirement not to override local changes.  While this may very well
>> not be the intention behind these policies, I'd understand them as such
>> that the related package (postfix-doc) must only [be able to] modify the
>> configuration file if it does not contain local changes.
>>
>> I.e., either the provided program (currently postconf) should refuse to
>> modify a locally modified configuration file, or the related package
>> (postfix-doc) should check for local changes itself.
>>
>> I am generally unsure, however, how detection of local modification is
>> supposed to work in practice without using conffiles.  I suppose a
>> second configuration file copy that is modified by postinst scripts, but
>> not the local administrator, should work.
> 
> Preserve local modifications means don't undo specific changes made by the 
> local 
> administrator.  It does not mean make no changes to a file that an 
> administrator has made changes to.  The use of postconf specifically enables 
> changing the values relevant to postfix-doc without disturbing anything else 
> in 
> the file.  I think this is fine.

I agree that preserving local changes does not generally mean not to
modify locally modified files.  (Even though I'd prefer it to mean that.)

However, unless I am mistaken, the postinst scripts do not preserve
local changes to the readme_directory and html_directory configuration
settings.

In practice (given postfix-doc is [being] installed), such local changes
probably either do not happen, or the values are exactly those set by
the postinst scripts.

That is, in such an unlikely case, the letter of the Policy would be
violated, I think, but it may still be considered fine in practice.  I
cannot assess that.

Einhard Leichtfuß

Reply via email to