Re: [PATCH setup 0/3] Setup replacement for incver_ifdep

[Jon Turney <jon.turney@dronecode.org.uk>]

On 15/10/2015 19:01, Achim Gratz wrote:
> Jon Turney writes:
>>> I still don't think the triggers should be implemented or at least not
>>> in the way you've been proposing.
>>
>> Can you explain the reason why?
>
> Triggers need to be coordinated among packages and we currently don't
> have an infrastructure for that.  And implementing just a single trigger
> for info files is special-casing this thing too much.
>
>> I think that's more or less what I implemented.
>
> I'm talking about doing it with a perpetual postinstall script.
>
>>> But it would be possible to just add /
>>> remove the corresponding entries with a bit more bookkeeping.  I'll try
>>> something of that, but not immediately.
>>
>> I guess that list of matching files added/removed could be written
>> into or associated with the trigger file, but the benefit starts to
>> look a bit marginal, (especially as this is not intended as a general
>> solution, but only for use with _update-info-dir, and other future
>> package-to-package triggers are written directly in the packages
>> themselves)
>
> Again, I don't see why updating the info dir should be so special, it
> can be done in postinstall without getting special-cased in setup:

I agree.

But I think the problem of coordination you mention can only be solved 
by (a) updating all ~155 packages which contain files in 
/usr/share/info, or (b) having something in setup or it's postinstall 
scripts which notices when a file is added/removed in that directory.

I don't think (a) is practical at the moment, although I hope it is 
clear in my proposal that I am suggesting that ultimately all those 
packages should create the trigger file in their postinstall/preremove 
scripts.

I still don't understand what alternative way to achieve (b) you are 
proposing.