Re: [Rpm-maint] upgrade process
Michael Schroeder wrote in Fri 03/20 2009 at 12:21 +0100: On Thu, Mar 19, 2009 at 05:49:21PM +0100, Stanislav Brabec wrote: Package smartsuite was renamed to smartmontools, but the script /etc/init.d/smartd remains without change. Start on installation, restart (once) on update, stop on removal. It's easy top do with package-name based scripts. That's a straightforward use case for %postinstall/%postupdate/%preuninstall Well, imagine more complicated case: Suppose we have all-in-one avahi package. Now we split (for a good reason) to: avahi: Contains /etc/init.d/avahi-daemon and /etc/init.d/avahi-dnsconfd avahi-python: Contains /etc/init.d/avahi-bookmarks But maybe packagers will decide: avahi-core: Contains /etc/init.d/avahi-daemon and /etc/init.d/avahi-dnsconfd avahi-python: Contains /etc/init.d/avahi-bookmarks Is it possible to restart each daemon once in this case? 2) [...] %postnew /usr/bin/gst-register /usr/bin/gst-register %postup /usr/bin/gst-register /usr/bin/gst-register %postrm /usr/bin/gst-register rm -r /var/cache/gstreamer-0.8 No no, you shouldn't do that with scriptlets at all, but with a virtual package trigger. Actually, yes for this example (gst-register will create cache of all plugins). What about a tool, which has a cache directory as a private playground of a particular binary: Imagine a package split: caching-proxy = caching-proxy-http + caching-proxy-ftp /usr/bin/cproxy-http uses /var/cache/cproxy/http /usr/bin/cproxy-ftp uses /var/cache/cproxy/ftp If you upgrade from caching-proxy to caching-proxy-http only, you probably want to purge /var/cache/cproxy/ftp. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz 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 http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] upgrade process
On Thu, Mar 19, 2009 at 05:49:21PM +0100, Stanislav Brabec wrote:
Package smartsuite was renamed to smartmontools, but the
script /etc/init.d/smartd remains without change. Start on installation,
restart (once) on update, stop on removal.
It's easy top do with package-name based scripts.
That's a straightforward use case for
%postinstall/%postupdate/%preuninstall
2)
[...]
%postnew /usr/bin/gst-register
/usr/bin/gst-register
%postup /usr/bin/gst-register
/usr/bin/gst-register
%postrm /usr/bin/gst-register
rm -r /var/cache/gstreamer-0.8
No no, you shouldn't do that with scriptlets at all, but with
a virtual package trigger.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] upgrade process
Michael Schroeder wrote in Fri 03/13 2009 at 17:24 +0100: so i am loosing the symlink as it gets removed by the postun in the old package - i guess i need to work on the install/upgrade/erase syntax in there but i am struggling to fins an example i fully understand!! There are two ways to detect if it's an update or not: A third way is an update-alternatives package and call of update-alternatives in %posttrans. I think we should thus extend rpm to make things easier. How about adding support for %update scriptlets? The order would be preup new install files from new delete files from old that are not shared postup new No preun/postun would be run in -U mode if the new package has a preup or postup scriptlet. rpm should also tell the up scripts wich packages in which versions were obsoleted. Maybe as a list of HDRNUMs so that the scriplets can do a --querybynumber. I have been thinking about it as well. Such simple definition may work in simple cases (foo-1.0 replaced by foo-1.1), but it will be problematic for more complicated cases: 1) Imagine that package foo-1 is going to be split to three sub-packages: foo-core-2, foo-plugins-base-2 and foo-plugins-extra-2. Now we are going to upgrade from foo-1 to foo-core-2+foo-plugins-base-2, omitting the foo-plugins-extra-2. Is it an upgrade or not? Possible solution: %prenew, %postnew, %preup, %postup, %prerm, %postrm could optionally refer to a particular file and would be called only if it is an new/update/removal for this file. 2) Imagine that package foo needs to run adduser fooser during the first installation and it should call deluser fooser on package removal. Now imagine that yet another package foof needs to do the same for the same user. Even after package foo removal, fooser should be defined. It should be removed only if none of foo and foof will be present. Possible solution: %prenew, %postnew, %preup, %postup, %prerm, %postrm could optionally refer to a virtual symbol and would be called only if it the symbol is new/non-zero number of providers changes/all providers removed for this file. 3) Imagine that non-conflicting packages foo and package oof provide the same function and both want to install compatibility script or symlink foo-or-oof. It should exist, if any of foo or oof are installed. Possible solution: Create a virtual symbol foo-or-oof-script and then continue with 2). %postnew foo-or-oof-script and %postrm foo-or-oof-script should do what you expect. The real problem you have is that there's no way to fix the bugs in scriptlets of the installed packages. Is it possible to introduce new feature removing selected script from the database? %blockscript package_name [= package version] script_type script_args %killscript package_name [= package version] script_type script_args %replacescript package_name [= package version] script_type script_args new contents of the script All these problems were already mentioned in http://www.rpm.org/wiki/Problems -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz 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 http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] upgrade process
On Thu, Mar 19, 2009 at 02:12:01PM +0100, Stanislav Brabec wrote:
I have been thinking about it as well. Such simple definition may work
in simple cases (foo-1.0 replaced by foo-1.1), but it will be
problematic for more complicated cases:
1) Imagine that package foo-1 is going to be split to three
sub-packages: foo-core-2, foo-plugins-base-2 and foo-plugins-extra-2.
Now we are going to upgrade from foo-1 to foo-core-2+foo-plugins-base-2,
omitting the foo-plugins-extra-2. Is it an upgrade or not?
If it obsoletes another package it's an upgrade.
2) Imagine that package foo needs to run adduser fooser during the
first installation and it should call deluser fooser on package
removal. Now imagine that yet another package foof needs to do the same
for the same user. Even after package foo removal, fooser should be
defined. It should be removed only if none of foo and foof will be
present.
This has an easy solution: *never* call deluser. You don't know if
there are some files owned by the user lurking somewhere in the
filesystem and you sure don't want them to belong to some other user
after the next adduser call.
3) Imagine that non-conflicting packages foo and package oof provide the
same function and both want to install compatibility script or symlink
foo-or-oof. It should exist, if any of foo or oof are installed.
Possible solution:
Create a virtual symbol foo-or-oof-script and then continue with 2).
%postnew foo-or-oof-script and %postrm foo-or-oof-script should do what
you expect.
Sounds like a job for update-alternatives. If you don't want that,
use %verify(not md5 size mtime link) and don't use a scriptlet at
all.
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] upgrade process
Michael Schroeder wrote in Thu 03/19 2009 at 15:35 +0100: 1) Imagine that package foo-1 is going to be split to three sub-packages: foo-core-2, foo-plugins-base-2 and foo-plugins-extra-2. Now we are going to upgrade from foo-1 to foo-core-2+foo-plugins-base-2, omitting the foo-plugins-extra-2. Is it an upgrade or not? If it obsoletes another package it's an upgrade. And what if the action you need is say foo-extra-update and foo-extra update was a part of foo-1 and later foo-plugins-extra-2? In real life, many actions are not relevant to package, but to an exact file name: - init script restart - purge of no more used directory - ... 2) Imagine that package foo needs to run adduser fooser during the first installation and it should call deluser fooser on package removal. Now imagine that yet another package foof needs to do the same for the same user. Even after package foo removal, fooser should be defined. It should be removed only if none of foo and foof will be present. This has an easy solution: *never* call deluser. You don't know if there are some files owned by the user lurking somewhere in the filesystem and you sure don't want them to belong to some other user after the next adduser call. Well, in case of adduser, it keeps just one orphan line. But packages may keep several megabytes of cache files, which become obsolete if all its consumers are removed. 3) Imagine that non-conflicting packages foo and package oof provide the same function and both want to install compatibility script or symlink foo-or-oof. It should exist, if any of foo or oof are installed. Possible solution: Create a virtual symbol foo-or-oof-script and then continue with 2). %postnew foo-or-oof-script and %postrm foo-or-oof-script should do what you expect. Sounds like a job for update-alternatives. If you don't want that, use %verify(not md5 size mtime link) and don't use a scriptlet at all. Yes, update-alternatives is the cleanest solution in this case. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz 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 http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] upgrade process
Michael Schroeder wrote in Thu 03/19 2009 at 16:49 +0100: On Thu, Mar 19, 2009 at 04:32:27PM +0100, Stanislav Brabec wrote: Michael Schroeder wrote in Thu 03/19 2009 at 15:35 +0100: If it obsoletes another package it's an upgrade. And what if the action you need is say foo-extra-update and foo-extra update was a part of foo-1 and later foo-plugins-extra-2? The action is done in the package containing foo-extra-update. But maybe I'm not really understanding your example, can you be a bit more concrete in the setup you're talking about? Possible examples from real life: 1) Package smartsuite was renamed to smartmontools, but the script /etc/init.d/smartd remains without change. Start on installation, restart (once) on update, stop on removal. It's easy top do with package-name based scripts. 2) Package gstreamer was split+renamed to gstreamer-0_8 libgstreamer-0_8 gstreamer-0_8-utils. You want to call gst-register just after finishing the update from gstreamer to gstreamer-0_8-utils. But if you if you decide to update just only a library, the gst-register cache should be deleted instead. In case of scripts assigned to package names, implementer must take extra care to prevent incorrect behavior in such cases. Featuring scripts assigned to files in the RPM database would be much straight-forward in more complicated cases: %postnew /usr/bin/gst-register /usr/bin/gst-register %postup /usr/bin/gst-register /usr/bin/gst-register %postrm /usr/bin/gst-register rm -r /var/cache/gstreamer-0.8 Well, the last line is again not error-proof: - After renaming of /usr/bin/gst-register to /usr/bin/gst-register-0.8 it will accidentally delete the whole directory (just exactly as it will happen in the example above with a simple %postun). - If developers decide to place another stuff to this directory, it may behave incorrectly as well. The idea below could provide a better solution. A cache file shared between different packages? It should be marked as %ghost in all of those packages so that it automatically is deleted when it's no longer needed. Using %ghost works well for files. But if the cache consist from an undefinable number of files in a whole directory which may become obsolete, and you want to purge the whole directory, you have a problem. Example: When we moved GNOME from /opt/gnome to /usr, we have had a hard time and super-ugly scripts ensuring that cache files in /opt/gnome/share/mime and /opt/gnome/share/applications disappeared only and only in the case that no application remains installed in /opt/gnome. -- Best Regards / S pozdravem, Stanislav Brabec software developer - SUSE LINUX, s. r. o. e-mail: sbra...@suse.cz 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 http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] upgrade process
thanks - i put this in the %postun # Only remove symlink if we are erasing package if [ $1 = 0 ]; then if [ -h /usr/java/latest ] ; then rm -f /usr/java/latest ; fi fi but on an upgrade the symlink still got wiped out. I was sure that looked right when compared to install erase upgrade reinstall %pre 1- 2 2 %post1- 2 2 %preun -0 1 - but seemingly not! %postun -0 1 - my bad - this in fact worked fine - reason it appeared to not was due to the fact that the previous package that was being removed was built without this and therefore removed the symlink. this now works as i expect which is great. thanks ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] upgrade process
On Fri, Mar 13, 2009 at 08:06:41AM -0500, Mark Hatle wrote:
New packages files installed
Old package files removed (ones not already overwritten by the install)
postun run
post run
Not really. The order is:
prein new
install files from new
postin new
preun old
delete files from old that are not shared
postun old
Cheers,
Michael.
--
Michael Schroeder m...@suse.de
SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
