Marc - A. Dahlhaus wrote:
Xavier schrieb:
On Fri, Sep 11, 2009 at 3:27 PM, Allan McRae <[email protected]>
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.
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.
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)
Allan
