[pacman-dev] [RFC] alpmtrigger: triggering events after all packages got installed...

[Marc - A. Dahlhaus]

Allan McRae schrieb:
> Marc - A. Dahlhaus wrote:
>> Xavier schrieb:
>>> On Fri, Sep 11, 2009 at 3:27 PM, Allan McRae <allan at archlinux.org> 
>>> wrote:
>>>> Reading this, I am not sure I understand your proposal.
>>>> You suggested:
>>>>
>>>> inside of a packages install-helper we would call
>>>> "alpmtrigger pkgtrigger" to set the trigger "pkgtrigger" active.
>>>>
>>>>
>>>> So each package needs an install file that contains just e.g. 
>>>> "alpmtrigger
>>>> infopage".  For every package that has info pages...  That still 
>>>> sounds like
>>>> duplication to me.
>>>> Given all we need to currently do for the install file for info 
>>>> pages is to
>>>> copy the prototype and list the info pages to install, you 
>>>> suggestion really
>>>> is no less work.
>>>>
>>>
>>> Another important question here :
>>> how are user hooks defined then ?
>>
>> I think we should distinct between triggers and what they are/provide 
>> and what hooks are/provide.
>>
>>
>>
>> The trigger approach is used to fire up well defined common tasks at a 
>> later point in the installation.
>>
>> Triggers are by design part of the package that provides them. They 
>> allow other packages to make usage of its functionality for common 
>> tasks at the end of a running transaction. They try to do such a 
>> common task one time during the whole transaction. There is no 
>> ordinary user of the distribution involved here by design as it has to 
>> just work for the user without user intervention.
> 
> How are other packages making use of the trigger if we are not letting 
> filenames set it off?   As I said in an earlier post, having to define 
> the trigger in an install file or similar removes the automation of the 
> hook which is pretty much the point here.  It would just result in 
> changing which .install file prototype is copied so would be no les work 
> for packagers.
> 
>>
>> The hook approach is used to fire up tasks on specific events during 
>> the package installation.
>>
>> Hooks are placed at defined spots to the codebase of libalpm and 
>> provide chains with as much hook-rules as got configured for it. The 
>> rules consists of "filename that got installed" based fire up of scripts.
>> (I think the remaining two hook types "once per transaction" and "for 
>> a given package" would be more or less like what i wrote about 
>> triggers above)
> 
> So the hook case actually covers _updating_ info and man_db databases 
> and installing gconf files.  While "updating" the info database by 
> deleting it and recreating it may be reasonably fast, it is a waste and 
> doing that for e.g. gconf files would be slow.
>

Point taken.

But what trigger try to achieve is a fully different thing:

They delay a common workload that the packager wants to be done for the 
package and that could be done for more than one package (thats why i 
use the term common) during the transaction to the and of it so that it 
is possible to run this workload only one time. Nothing more.

If we don't want to add it into an install sctiptlet, then we could even 
add an trigger array to PKGBUILD to give the packager the possibility to 
ask for a trigger.

I argue that hooks try to achieve a very different thing and should be 
designed in a different way than the end-of-transaction workload 
triggers because they are different things.

>> The question is do we really need this chain of rules for each 
>> proposed hook in libalpm thing which needs to scan for all the defined 
>> filename or package-name rules and will it be worth the effort to 
>> implement it if just a few packages ever will make use of the hooks. 
>> How often will we look at matching hook rules during normal operation? 
>> I'll bet not quite often.
>>
>> I think this approach would also waste quite a few resources on every 
>> transaction to search for matches without even knowing if some package 
>> would trigger such an event. It has to do that every time as there is 
>> no "i want this hook to get fired up" action from the package-side as 
>> it would in the trigger approach. I think to list the content of one 
>> or more directories and fire up scriptlets based on files found would 
>> clearly outperform the scanning of every file that gets installed 
>> based on N rules we need to match against.
> 
> Don't we already generate lists of files for conflict checking? So 
> scanning that list for matches to hooks will be a relatively low cost 
> operation.

Do we have information about what will get removed and what will get 
added to the filesystem after the conflict checking is done?

So we need hook scripts that might take a second param and are fired up 
for every file for the info, man-db or gconf workload?

$1 : filename
$2 (file-action): add or remove


>> I think we could achieve anything we could think of with the trigger 
>> approach from the packagers perspective except giving the user the 
>> ability to install hooks on this users self defined event-rules...
>>
>> `If a user really wants to add a script which fires up if some 
>> filename based event is fulfilled than this user should take a look at 
>> the incron package and use it for what it was made IMO.
> 
> Yes, and using incron does somewhat work for installing info pages.  But 
> it fails because it does not monitor changes in subdirectories.  In the 
> case of info pages, users would then need to have incron running for 
> something a package manager for a distro should do.
> 
> 
> Please correct me if I am wrong, but the reasons I do not like the 
> "triggers" idea are:
> 1) I need to set off the trigger in the install file.  So this just 
> replaces copying one prototype with another. 2) It requires regenerating 
> databases rather than updating them.  That overhead will be large for 
> some operations (e.g. gconf)

1: As stated above, triggers are activated by packages that want them by 
design as they try to achieve to do workload that is currently done many 
times on large transactions only once at the end of them. So there is a 
need to add the information to the package itself.

2: That's irrelevant for the trigger approach as i wanted to just show 
that you can achieve more or less the same results with triggers. The 
install-info thing was an example, nothing more. I fully agree with you 
on that for this kind of workload the hook system would be a clean 
implementation and possibly the right thing to do.



I'm not against implementing the hook approach at all, but i think the 
triggers are a good functionality and even easy to implement. And as 
they don't operate on the "fired up by a file add or remove" paradigm 
that the hooks would use, they should be implemented in a different way.

Also i still have the opinion that the configuration of a hook-script 
should be contained in the script itself as this is the only way that i 
could come up with at the moment that would activate the hook 
automatically on installation of the hook. Another way would be to add 
the hook configuration into the database and parse this info from there. 
But the user created hooks would only work if the user builds his own 
hook-package then...

Another problem with hooks and the points on which they should be 
executed is that if you have a large transaction in which some packages 
add hooks that are needed for packages that are installed in the same 
transaction need to be parsed on installation time to give you the 
option to run the hooks on the point they should be executed. Also what 
about a package that wants hook X needs to be installed before the hook 
X is added by another package? Would be a classic chicken-egg problem i 
think. Trigges like i proposed them don't have this problem as they get 
executed after the transaction is completed. At this point all triggers 
are where they should be.


Marc