Re: [Rpm-maint] discussion on problems of RPM in real life packaging
Seth Vidal wrote: %pretans plays all sorts of hell with chroot installs. We tend to discourage them as much as possible. Why they are different than %post in chroot? I guess that there were some implementation problems in rpm, for example: https://bugzilla.novell.com/show_bug.cgi?id=235361 -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] discussion on problems of RPM in real life packaging
Pixel wrote: Stanislav Brabec [EMAIL PROTECTED] writes: Using %preun is acceptable only for uninstallation, not for upgrade. But this is yet another problem mentioned in the document, not related to one-time-scriptlets. oops, right. mandriva never went that far :) http://bugzilla.gnome.org/show_bug.cgi?id=306924 https://bugzilla.novell.com/show_bug.cgi?id=48114 However I can imagine an one-time unsubscription counterpart (something, which will evaluate list of all files going to be removed or overwritten in the forthcoming transaction and then issue a command with a such list. I think it could be possible to write it as well, but only deep inside the rpm (when rpm evaluates possible conflicts in forthcoming transaction). it should not be very hard to have pretrans filetriggers, but it would be dangerous if the transaction somehow fails. eg: the gconf schema gets uninstalled in %prettrans, but a rollback re-adding it would be necessary on failure. And even if rollback was handled nicely, it would imply some unnecessary uninstall of schema (since the install will handle existing schema). Current %pretrans (or something like it) is not suitable for it - it is called from installed instance. We need a scriptlet like %preuntrans (or %unpretrans) - the same as %pretrans, but called from removed instance. A solution could be: files needing subscription/unsubscription could be renamed to .rpmprevious instead of being removed ; then used in filetrigger, and only removed what all this is done. Still, the filetrigger script would need to be able to check the difference between previous and new file, to know what to do, which may not be easy... Maybe better would be adding new files as .rpmnew and putting them in place after successful unsubscription: - scripts may be file name sensitive - this concept already exists in rpm for %config files, it means only few additional changes to place them. I can imagine %safe_update tag in the file list. But even then, it would require more changes than only the above to make such scripts effective. Concept of rollback scripts is missing in rpm. If something fails, these files would remain forever. I don't know, what is worse - orphan files, orphan records in the database, missing records in the database. Debian has advanced script concept: http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] discussion on problems of RPM in real life packaging
Seth Vidal [EMAIL PROTECTED] writes: On Mon, 16 Jun 2008, Pixel wrote: However I can imagine an one-time unsubscription counterpart (something, which will evaluate list of all files going to be removed or overwritten in the forthcoming transaction and then issue a command with a such list. I think it could be possible to write it as well, but only deep inside the rpm (when rpm evaluates possible conflicts in forthcoming transaction). it should not be very hard to have pretrans filetriggers, but it would be dangerous if the transaction somehow fails. %pretans plays all sorts of hell with chroot installs. We tend to discourage them as much as possible. hum, i was not very clear. what i really meant is filetriggers running at %pretrans time as noted by Stanislav, they would be more like %preuntrans. but anyway, this is not important since it would be a wrong solution :) ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] discussion on problems of RPM in real life packaging
Pixel wrote: Stanislav Brabec [EMAIL PROTECTED] writes: Particular problems there may have different severity and different complexity. The worst one seems to be Problems of Scriptlets / Database rebuild. mandriva is currently experimenting something on this subject: http://wiki.mandriva.com/en/Rpm_filetriggers implementation is quite rough and simple: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.4.2.3-filetriggers.patch?view=log Mandriva patch defines patterns evaluated by RPM runtime. + simple global adding of new directories + simple global adding of new scripts (e. g. gtk-update-icon-cache for KDE apps, if GTK+ is installed). - needs pattern evaluation in runtime - to enable this feature, adding a line to spec is required (implementation problem only) * 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. 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 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 - File queue looks ugly. The best place to evaluate triggers would be writing to rpmdb. - And finally, application, which provides a new trigger script, should trigger its initial run. - Trigger script should have removal procedure defined. 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) 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. Triggers on virtual symbols may appear as well, but they are not ideal for implementing of general one time triggers. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] discussion on problems of RPM in real life packaging
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
Re: [Rpm-maint] discussion on problems of RPM in real life packaging
Pixel wrote: 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. Well, there is still a problem, that there is not any scriptlet, which is called from the instance, which is going to be deleted, but in the moment, when all old-instance files are still present and unmodified. Using %preun is acceptable only for uninstallation, not for upgrade. But this is yet another problem mentioned in the document, not related to one-time-scriptlets. 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\. ?) Using file lists on stdin of the one time script may be very useful for scripts of subscription type, if the scripted tool can handle more than one file at once. However I can imagine an one-time unsubscription counterpart (something, which will evaluate list of all files going to be removed or overwritten in the forthcoming transaction and then issue a command with a such list. I think it could be possible to write it as well, but only deep inside the rpm (when rpm evaluates possible conflicts in forthcoming transaction). -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: [EMAIL PROTECTED] Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republichttp://www.suse.cz/ ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] discussion on problems of RPM in real life packaging
Stanislav Brabec [EMAIL PROTECTED] writes: [...] Using %preun is acceptable only for uninstallation, not for upgrade. But this is yet another problem mentioned in the document, not related to one-time-scriptlets. oops, right. mandriva never went that far :) [...] However I can imagine an one-time unsubscription counterpart (something, which will evaluate list of all files going to be removed or overwritten in the forthcoming transaction and then issue a command with a such list. I think it could be possible to write it as well, but only deep inside the rpm (when rpm evaluates possible conflicts in forthcoming transaction). it should not be very hard to have pretrans filetriggers, but it would be dangerous if the transaction somehow fails. eg: the gconf schema gets uninstalled in %prettrans, but a rollback re-adding it would be necessary on failure. And even if rollback was handled nicely, it would imply some unnecessary uninstall of schema (since the install will handle existing schema). A solution could be: files needing subscription/unsubscription could be renamed to .rpmprevious instead of being removed ; then used in filetrigger, and only removed what all this is done. Still, the filetrigger script would need to be able to check the difference between previous and new file, to know what to do, which may not be easy... ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] discussion on problems of RPM in real life packaging
On Mon, 16 Jun 2008, Pixel wrote: However I can imagine an one-time unsubscription counterpart (something, which will evaluate list of all files going to be removed or overwritten in the forthcoming transaction and then issue a command with a such list. I think it could be possible to write it as well, but only deep inside the rpm (when rpm evaluates possible conflicts in forthcoming transaction). it should not be very hard to have pretrans filetriggers, but it would be dangerous if the transaction somehow fails. %pretans plays all sorts of hell with chroot installs. We tend to discourage them as much as possible. -sv ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] discussion on problems of RPM in real life packaging
Stanislav Brabec [EMAIL PROTECTED] writes: Particular problems there may have different severity and different complexity. The worst one seems to be Problems of Scriptlets / Database rebuild. mandriva is currently experimenting something on this subject: http://wiki.mandriva.com/en/Rpm_filetriggers implementation is quite rough and simple: http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/rpm/current/SOURCES/rpm-4.4.2.3-filetriggers.patch?view=log ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
