[zypp-devel] [Fwd: SuSEconfig and PackageKit]
-------- Original Message --------
Subject: SuSEconfig and PackageKit
Date: Thu, 22 Jan 2009 02:13:20 +0100
From: Scott Reeves
Duncan Mac-Vicar Prett wrote:
Hi, I'm unsure about what our general policy is regarding when SuSEconfig should be run and also specifically regarding PackageKit zypp backend. Does PackageKit need to run this on system updates or individual package installs? Does libzypp take care of this under the covers ( for instance does zypp:ZYpp:commit call SuSEconfig at the end of the method?)
You need to call SuSEconfig just once before you "return updated system to the user". -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thu, Jan 22, 2009 at 05:56:56PM +0100, Stanislav Brabec wrote:
Duncan Mac-Vicar Prett wrote:
I'm unsure about what our general policy is regarding when SuSEconfig should be run and also specifically regarding PackageKit zypp backend. Does PackageKit need to run this on system updates or individual package installs? Does libzypp take care of this under the covers ( for instance does zypp:ZYpp:commit call SuSEconfig at the end of the method?)
You need to call SuSEconfig just once before you "return updated system to the user".
If zypper doesn't do it, why should PackageKit? Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schroeder napsal(a):
On Thu, Jan 22, 2009 at 05:56:56PM +0100, Stanislav Brabec wrote:
Duncan Mac-Vicar Prett wrote:
I'm unsure about what our general policy is regarding when SuSEconfig should be run and also specifically regarding PackageKit zypp backend. Does PackageKit need to run this on system updates or individual package installs? Does libzypp take care of this under the covers ( for instance does zypp:ZYpp:commit call SuSEconfig at the end of the method?) You need to call SuSEconfig just once before you "return updated system to the user".
If zypper doesn't do it, why should PackageKit?
We had better finally drop SuSEconfig from SUSE than adding the same hack to several places in the system. Bye Lukas -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl4xEgACgkQVSqMdRCqTiy/wACcC8FSSBrfrLski8sRQK9i5oL9 NbAAn10d4Jitt0GUhIs6b64t6B2O+pd1 =48YY -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Lukas Ocilka
We had better finally drop SuSEconfig from SUSE than adding the same hack to several places in the system.
I couldn't agree more. However, dropping SuSEconfig has been tried several times before in the past and ... its still there. So either its more effort than expected or not sufficient interest in dropping it (or both ;-)). Maybe 'dropping SuSEconfig' can be turned into a community effort, like 'faster booting' which was just announced on opensuse-factory. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
* Lukas Ocilka
[Jan 22. 2009 20:09]: We had better finally drop SuSEconfig from SUSE than adding the same hack to several places in the system.
I couldn't agree more.
However, dropping SuSEconfig has been tried several times before in the past and ... its still there.
So either its more effort than expected or not sufficient interest in dropping it (or both ;-)). It's definitely both. rpm just sucks with delaying long running taks till all
Am Freitag 23 Januar 2009 schrieb Klaus Kaempf: packages are installed the require that long running task. Greetings, Stephan -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Lukas Ocilka wrote:
We had better finally drop SuSEconfig from SUSE than adding the same hack to several places in the system.
I agree. We can drop in just now. But with rpm alone, distro installation time will increase to 2-3 hours or even more. To fix this problem, we need one-shot post transaction triggers on virtual symbols in rpm and installation must use transactions. Otherwise there is no way to say: If package contains foo (MIME type description, desktop file, theme icon, font, shared library, info file, browser plugin,...), call this just once after finishing the installation (or transaction, or before starting to do anything). https://features.opensuse.org/305472 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Lukas Ocilka escribió:
We had better finally drop SuSEconfig from SUSE than adding the same hack to several places in the system.
Yes, and gtk-update-icon-cache should be fixed to be fast, it is just silly to call SUSEconfig in hundred of packages just due to a single slow cache updater. -- "We have art in order not to die of the truth" - Friedrich Nietzsche Cristian Rodríguez R. Software Developer Platform/OpenSUSE - Core Services SUSE LINUX Products GmbH Research & Development http://www.opensuse.org/
Cristian Rodríguez wrote:
Lukas Ocilka escribió:
We had better finally drop SuSEconfig from SUSE than adding the same hack to several places in the system.
Yes, and gtk-update-icon-cache should be fixed to be fast, it is just silly to call SUSEconfig in hundred of packages just due to a single slow cache updater.
Even if it will be fast, you would have to change hundreds of packages to live without SuSEconfig. If the virtual trigger feature will exist, it would be just two lines. One line in the default find-requires (file in /usr/share/icons => add a virtual symbol provides_icon), second triggering gtk-update-icon cache in gtk2. Such feature would save tens of hours of packagers work and prevent mistakes (forgotten scriptlets). -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
2009/1/23 Stanislav Brabec
Cristian Rodríguez wrote:
Lukas Ocilka escribió:
We had better finally drop SuSEconfig from SUSE than adding the same hack to several places in the system.
Yes, and gtk-update-icon-cache should be fixed to be fast, it is just silly to call SUSEconfig in hundred of packages just due to a single slow cache updater.
Even if it will be fast, you would have to change hundreds of packages to live without SuSEconfig.
If the virtual trigger feature will exist, it would be just two lines. One line in the default find-requires (file in /usr/share/icons => add a virtual symbol provides_icon), second triggering gtk-update-icon cache in gtk2.
Such feature would save tens of hours of packagers work and prevent mistakes (forgotten scriptlets).
Yes. I have to agree. I worked once on a very custom package management system which supported the idea of a trigger and a delayed trigger. The mere presence of changes in certain directories or files would trigger it (optionally delayed). Thus, new font packages would set up triggers which would get run at the very end of the installation, and if 15 font packages got installed the trigger still only ran once. Ditto for the gtk icon and schema stuff and so on. Is there any provision for that with RPM? Can you go into more detail regarding these virtual triggers? They sound like a really good idea. -- Jon -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Jon Nelson wrote:
Can you go into more detail regarding these virtual triggers? They sound like a really good idea.
Here is a comprehensive list of problems that packagers meet every day while creating RPM packages: http://www.rpm.org/wiki/Problems Feel free to comment it. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Fri, Jan 23, 2009 at 10:49:58AM -0600, Jon Nelson wrote:
Can you go into more detail regarding these virtual triggers? They sound like a really good idea.
The idea is pretty simple: Currently rpm triggers just work on package names. If they would also consider the "Provides" of a package, we could change rpm's find-provides script so that it automatically adds a Provides: trigger(gtk-update-icon-cache) if the filelist contains an icon. Now, some other package would contain a trigger scriptlet that triggers on "trigger(gtk-update-icon-cache)", this scriptlet then would call the gtk-update-icon-cache application. The advantage is that packagers don't need to put scriptlets in their package, thus mistakes are reduced. Triggers could also be used for other things which currently are done by scriptlets, e.g. - run ldconfig - add a new user/group - index "info" documentation - make multimedia plugins available In short, we want to get rid of most scriptlets. Now, whether there will be "transaction" or "one-shot" triggers, that's still to be discussed. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Michael Schroeder wrote:
On Thu, Jan 22, 2009 at 05:56:56PM +0100, Stanislav Brabec wrote:
Duncan Mac-Vicar Prett wrote:
I'm unsure about what our general policy is regarding when SuSEconfig should be run and also specifically regarding PackageKit zypp backend. Does PackageKit need to run this on system updates or individual package installs? Does libzypp take care of this under the covers ( for instance does zypp:ZYpp:commit call SuSEconfig at the end of the method?)
You need to call SuSEconfig just once before you "return updated system to the user".
If zypper doesn't do it, why should PackageKit?
Zypper should as well. But does not. It may have ugly sonsequences while installing some packages (missing icons, MIME binding,...) https://bugzilla.novell.com/show_bug.cgi?id=365649 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Fri, Jan 23, 2009 at 12:20:43PM +0100, Stanislav Brabec wrote:
Zypper should as well. But does not. It may have ugly sonsequences while installing some packages (missing icons, MIME binding,...)
That just means you should make gtk-update-icon-cache faster. One way to do it would be to add an "incremental" mode. This mode would take a file list as argument and only add/remove files from this file list. (We had the same problem with "ldconfig", everybody complained that it too ages to run. So we fixed it to be fast.) Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Michael Schroeder wrote:
On Fri, Jan 23, 2009 at 12:20:43PM +0100, Stanislav Brabec wrote:
Zypper should as well. But does not. It may have ugly sonsequences while installing some packages (missing icons, MIME binding,...)
That just means you should make gtk-update-icon-cache faster. One way to do it would be to add an "incremental" mode. This mode would take a file list as argument and only add/remove files from this file list.
gtk-update-icon-cache has to inspect ~650 icon directories. With a non-trivial amount of work it is possible to rewrite it to be incremental. With another non-trivial amount of work, we may implement incremental fc-cache, later maybe other similar programs. Why not add one feature to RPM instead of complicated rewrites? -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Fri, Jan 23, 2009 at 01:20:22PM +0100, Stanislav Brabec wrote:
Michael Schroeder wrote:
On Fri, Jan 23, 2009 at 12:20:43PM +0100, Stanislav Brabec wrote:
Zypper should as well. But does not. It may have ugly sonsequences while installing some packages (missing icons, MIME binding,...)
That just means you should make gtk-update-icon-cache faster. One way to do it would be to add an "incremental" mode. This mode would take a file list as argument and only add/remove files from this file list.
gtk-update-icon-cache has to inspect ~650 icon directories.
Not if it gets a file list.
With a non-trivial amount of work it is possible to rewrite it to be incremental.
With another non-trivial amount of work, we may implement incremental fc-cache, later maybe other similar programs.
Why not add one feature to RPM instead of complicated rewrites?
Because your rpm feature causes problems if transactions get interrupted. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michael Schroeder wrote:
On Fri, Jan 23, 2009 at 01:20:22PM +0100, Stanislav Brabec wrote:
Michael Schroeder wrote:
On Fri, Jan 23, 2009 at 12:20:43PM +0100, Stanislav Brabec wrote:
Zypper should as well. But does not. It may have ugly sonsequences while installing some packages (missing icons, MIME binding,...)
https://bugzilla.novell.com/show_bug.cgi?id=365649 That just means you should make gtk-update-icon-cache faster. One way to do it would be to add an "incremental" mode. This mode would take a file list as argument and only add/remove files from this file list. gtk-update-icon-cache has to inspect ~650 icon directories.
Not if it gets a file list.
With a non-trivial amount of work it is possible to rewrite it to be incremental.
With another non-trivial amount of work, we may implement incremental fc-cache, later maybe other similar programs.
Why not add one feature to RPM instead of complicated rewrites?
Because your rpm feature causes problems if transactions get interrupted.
Hmm, but the feature should be implemented to cope with that :O) rpm could write the 'TODO' list to a file during a transaction. If interrupted, it would run also the older actions from the file. Or? - -- cheers, jano Ján Kupec YaST team - ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 - ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz - ---------------------------------------------------------(EOF)--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl5yHsACgkQgEhGpmN+6QHSDwCeIhLKXDSjqQZKTErDYid8TfmR ZCIAni/NOrRoTg8vhn4nNKW8gpnNxYC9 =1p3w -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Fri, Jan 23, 2009 at 02:39:07PM +0100, Jan Kupec wrote:
Hmm, but the feature should be implemented to cope with that :O) rpm could write the 'TODO' list to a file during a transaction. If interrupted, it would run also the older actions from the file. Or?
So "SuSEconfig" is just badly coded? Because that's also how SuSEconfig could work. As a side note, you also have the ldconfig problem: maybe some other package's scriptlet needs to have an up-to-date gtk icon cache, so it may not be correct to delay the cache generation to the end of the transaction. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Michael Schroeder wrote:
As a side note, you also have the ldconfig problem: maybe some other package's scriptlet needs to have an up-to-date gtk icon cache, so it may not be correct to delay the cache generation to the end of the transaction.
Cache is needed to display icons, not to process package installation. For programs like ldconfig it is more complicated. Suppose that we will implement one time triggers and move ldconfig there. Now let's have a packages: liba b (requires liba) c PreReq: b (e. g. Requires(post)) Nowadays you can install all at once using ldconfig is called by each shared library, b is working when c starts b inside script. With post transaction triggers, a b c would not be installable during a single transaction and the installation batch has to be split to two transactions: a b c -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Michael Schroeder wrote:
On Fri, Jan 23, 2009 at 01:20:22PM +0100, Stanislav Brabec wrote:
gtk-update-icon-cache has to inspect ~650 icon directories.
Not if it gets a file list.
"Automatically provide (relevant part of) the file list to script": This feature is missing in rpm as well. Hopefully it is possible to work-around it in the spec file by adding yet another %find_something macro and a bit of manual work. (see /etc/rpm/macros.gconf2 for example)
Why not add one feature to RPM instead of complicated rewrites?
Because your rpm feature causes problems if transactions get interrupted.
Is this problem different from a standard per-package %posttrans? I guess that it may be even less problematic: In case of one time script, you can call the script even after failure. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Fri, Jan 23, 2009 at 02:55:50PM +0100, Stanislav Brabec wrote:
Is this problem different from a standard per-package %posttrans?
Of course not, that's why I hate %postscript. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stanislav Brabec wrote:
Michael Schroeder wrote:
On Thu, Jan 22, 2009 at 05:56:56PM +0100, Stanislav Brabec wrote:
Duncan Mac-Vicar Prett wrote:
I'm unsure about what our general policy is regarding when SuSEconfig should be run and also specifically regarding PackageKit zypp backend. Does PackageKit need to run this on system updates or individual package installs? Does libzypp take care of this under the covers ( for instance does zypp:ZYpp:commit call SuSEconfig at the end of the method?) You need to call SuSEconfig just once before you "return updated system to the user". If zypper doesn't do it, why should PackageKit?
Zypper should as well. But does not. It may have ugly sonsequences while installing some packages (missing icons, MIME binding,...)
Just to avoid confusion: are you sure? That would imply the need to run SuSEConfig after any 'rpm -i/-U'!
That was a bug in the package, the package can't just rely on SuSEConfig will be run after it installs. Only in case YAST_IS_RUNNING is set (as jsrain pointed out in his mail). So while i agree with you that this needs to be solved at rpm level (as you pointed out in the other mail), it is not true zypper should run SuSEConfig because bugs in packages can have consequences if it is not run. Please let's be clear on that. - -- cheers, jano Ján Kupec YaST team - ---------------------------------------------------------(PGP)--- Key ID: 637EE901 Fingerprint: 93B9 C79B 2D20 51C3 800B E09B 8048 46A6 637E E901 - ---------------------------------------------------------(IRC)--- Server: irc.freenode.net Nick: jniq Channels: #zypp #yast #suse #susecz - ---------------------------------------------------------(EOF)--- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkl5sJ8ACgkQgEhGpmN+6QEfmwCeJ6nLwKHAULwc5WkQJE6cnAs5 7w0AmwTpR2SNqzE7GXTiXDVBP3zQiT2U =dO6V -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Jan Kupec wrote:
Zypper should as well. But does not. It may have ugly sonsequences while installing some packages (missing icons, MIME binding,...)
Just to avoid confusion: are you sure? That would imply the need to run SuSEConfig after any 'rpm -i/-U'!
Yes. If you are using RPM directly, call SuSEconfig.
That was a bug in the package, the package can't just rely on SuSEConfig will be run after it installs. Only in case YAST_IS_RUNNING is set (as jsrain pointed out in his mail).
So while i agree with you that this needs to be solved at rpm level (as you pointed out in the other mail), it is not true zypper should run SuSEConfig because bugs in packages can have consequences if it is not run. Please let's be clear on that.
Well, YAST_IS_RUNNING is not implemented in most packages. Implementing it to packages would make zypper installation much slower than YaST and will require following change in ~500 packages (including KDE, XFCE and other non-GTK+ desktop applications...): %posttrans if test -t "$YAST_IS_RUNNING" ; then if test -f /usr/bin/gtk-update-icon-cache ; then /usr/bin/gtk-update-icon-cache fi if test -f /usr/bin/update-desktop-database ; then /usr/bin/update-desktop-database fi fi -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +420 284 028 966, +49 911 740538747 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
Dne čtvrtek 22 Leden 2009 17:56:56 Stanislav Brabec napsal(a):
Duncan Mac-Vicar Prett wrote:
Hi, I'm unsure about what our general policy is regarding when SuSEconfig should be run and also specifically regarding PackageKit zypp backend. Does PackageKit need to run this on system updates or individual package installs? Does libzypp take care of this under the covers ( for instance does zypp:ZYpp:commit call SuSEconfig at the end of the method?)
You need to call SuSEconfig just once before you "return updated system to the user".
It makes sense run SuSEconfig in YaST after installing distro, since the same scripts would have been run several times (e.g. some stuff related to post- install scripts of fonts, IIRC), and YaST also sets the YAST_IS_RUNNING variable so that packages can know that SuSEconfig will be run. There is nothing similar in zypper or PackageKit; since when doing update, you typically update a few packages, it does not make much sense to change it IMO. Additionally, plain 'rpm -U' has to work as well. Jiri -- Regards, Jiri Srain YaST Team Leader --------------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: jsrain@suse.cz Lihovarska 1060/12 tel: +420 284 028 959 190 00 Praha 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (10)
-
Cristian Rodríguez
-
Duncan Mac-Vicar Prett
-
Jan Kupec
-
Jiri Srain
-
Jon Nelson
-
Klaus Kaempf
-
Lukas Ocilka
-
Michael Schroeder
-
Stanislav Brabec
-
Stephan Kulow