Stanislav Brabec <[EMAIL PROTECTED]> writes: [...]
> Mandriva patch defines patterns evaluated by RPM runtime. [...] > * no, install-info is not a good candidate fot this technique, > see http://wiki.rpm.org/Problems_of_Scriptlets (this is an > implementation of "Database rebuild", install info needs "Registry, > which needs subscription and unsubscription". well. more precisely, the patch allows to get rid of %post/%postun, but not %preun. "registration" can be handled: for gconf schema, we've removed the %post and kept the %preun "gconftool-2 --makefile-uninstall-rule" on uninstall. The advantage is doing all --makefile-install-rule at once instead of doing them in each %post. the other advantage is to ensure the --makefile-install-rule is always properly done. "subscription" also imply the "filetrigger" is installed in the same transaction (otherwise the subscription will never be done). But a full "subscription" of everything around could be done (see "initial run" below) "unsubscription" can't be handled easily using this scheme. (mandriva is keeping install-info management done by hand in %post/%preun) > My idea of function is very similar, but idea of implementation was > different: Adding a dedicated virtual symbol created by autoreq/prov > scripts and triggering these scripts by this symbol. > - adding new directory means rebuild (not a big problem) > - impossible to assign new script to existing package > + no pattern evaluation in runtime yeah, such a solution would be nice too, less expansive at runtime, and would allow unsubscription. maybe we could evolve later a solution that would do a mix of both... hum, quite complex though :-/ > Summary: Mandriva solution looks a bit more powerful. > >>From implementation level of Mandriva patch: > - Regexp evaluation is a bit expensive. In real, we need only: > - list of directories to be inspected > - list of (glob-style) patterns initiating the trigger > - information, whether triggering should occur in sub-directories using regexp was the easiest for an easy/quite-fast/no-bug implementation. but of course, it may be overkill. For info the "filters" currently in mandriva: ^.(/lib|/usr/lib)/[^/]*\.so\. ^./usr/share/applications/.*\.desktop$ ^./usr/share/mime/packages/[^/]*\.xml$ ^./usr/share/omf/.*\.omf$ ^./usr/share/icons/gnome/ ^./usr/share/icons/hicolor/ ^./usr/share/icons/oxygen/ ^\+/etc/gconf/schemas/[^/]*\.schemas$ > - File queue looks ugly. The best place to evaluate triggers would be > writing to rpmdb. agreed > - And finally, application, which provides a new trigger script, should > trigger its initial run. right. i've not handled this since such packages must surely already handle this by hand. for filetriggers not using the list of files passed in stdin (ie the filetriggers doing "Database rebuild"), it would be easy to add, we just need to call the filetrigger with nothing in stdin. but for filetriggers using the list of files passed in stdin (ie the filetriggers doing "subscription"), we would have to pass the files on filesystem matching regexp (not that easy to do using a regexp for the filter, eg: how do we get files matching ^.(/lib|/usr/lib)/[^/]*\.so\. ?) > - Trigger script should have removal procedure defined. agreed, it would be cleaner. [...] > Third idea mentioned in the thread was an uniq call on scripts. To > achieve the same, it proposes a completely different technique: > + (Maybe) simple to implement. > - Packagers still need to write scriptlets manually (including > cross-desktop scriptlets, e. g. gtk-update-icon-cache for koffice to > render correctly in GNOME menu). > - In worst case, complexity n^2 > - Fragile (needs exact string match in scriptlets) one more cons: - modifying the scriptlet implies modifying all the spec files. in any case, much too fragile IMO. > Summary: I would like to propose to accept > rpm-4.4.2.3-filetriggers.patch as an intermediate solution enabling > %_filetriggers_dir by default. We will collect packaging experiences. > > Later, when more clean (and more invasive) patch appear, adopting it > would not be expensive. In worst case, it would require trigger > conditionals rewrite. that's what i thought when doing it :) _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
