[zypp-devel] package dependency problem with zypper or yast
Hi, I'm building rpm packages for EGroupware (www.egroupware.org). They have a "metapackage" requiring the default modules and then executing a post_install script (create database, install EGroupware and all modules via a comand line client). All modules depend of a core module, which is also required by the metapackage and which includes the post-install script itself. (That way you can use the metapackage for convenience, but you can also install the single packages, if you want to). What I expect would be the following behaviour: 1. Install required packages (including required core package) 2. Install metapackage 3. Execute post install of metapackage (That's eg. the behaviour of yum or aptitude). What happens is the following: 1. Install some of the required packages 2. Install metapackage 3. Execute post install (which fails, because not all modules there) 4. Install some more required packages and core package I dont understand the reason behind that behaviour and could not find a way around it. The required packages installed after the metapackage always changing a bit - thought the majority of the packages is installed before, but not all. I already tried with openSUSE11.1 and SLES11: - PreReq Tag with core package name or file-name - several ways to background a helper script waiting for all files to appear in the filesystem - zypper always detects it and waits patiently for it to exit ;-) - explicitly specify the core package first on command line: zypper install egroupware-core egroupware Any help is welcome, thanks :-) Please CC me in your replies, as I'm not subscribed to this list. Ralf Ps: I can supply spec file, logs or a repository file to reproduce -- Ralf Becker Director Software Development Stylite GmbH [open style of IT] Morschheimer Strasse 15 67292 Kirchheimbolanden fon +49 (0) 6352 70629-0 fax +49 (0) 6352 70629-30 mailto: rb@stylite.de www.stylite.de www.egroupware.org ________________________________________________ Geschäftsführer Andre Keller, Gudrun Müller, Nigel Vickers und Ralf Becker Registergericht Kaiserslautern HRB 30575 Umsatzsteuer-Id / VAT-Id: DE214280951 -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thu, Jun 25, 2009 at 12:42:11PM +0200, Ralf Becker wrote:
I'm building rpm packages for EGroupware (www.egroupware.org). They have a "metapackage" requiring the default modules and then executing a post_install script (create database, install EGroupware and all modules via a comand line client). All modules depend of a core module, which is also required by the metapackage and which includes the post-install script itself. (That way you can use the metapackage for convenience, but you can also install the single packages, if you want to).
What I expect would be the following behaviour:
1. Install required packages (including required core package) 2. Install metapackage 3. Execute post install of metapackage
(That's eg. the behaviour of yum or aptitude).
What happens is the following:
1. Install some of the required packages 2. Install metapackage 3. Execute post install (which fails, because not all modules there) 4. Install some more required packages and core package
I dont understand the reason behind that behaviour and could not find a way around it. The required packages installed after the metapackage always changing a bit - thought the majority of the packages is installed before, but not all.
I already tried with openSUSE11.1 and SLES11: - PreReq Tag with core package name or file-name - several ways to background a helper script waiting for all files to appear in the filesystem - zypper always detects it and waits patiently for it to exit ;-) - explicitly specify the core package first on command line: zypper install egroupware-core egroupware
Any help is welcome, thanks :-)
Please attach a solver testcase, i.e. a tar of the driectory created by zypper install --debug-solver egroupware-core egroupware Thanks, 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
On Thu, Jun 25, 2009 at 12:42:11PM +0200, Ralf Becker wrote:
I'm building rpm packages for EGroupware (www.egroupware.org). They have a "metapackage" requiring the default modules and then executing a post_install script (create database, install EGroupware and all modules via a comand line client). All modules depend of a core module, which is also required by the metapackage and which includes the post-install script itself. (That way you can use the metapackage for convenience, but you can also install the single packages, if you want to).
What I expect would be the following behaviour:
1. Install required packages (including required core package) 2. Install metapackage 3. Execute post install of metapackage
(That's eg. the behaviour of yum or aptitude).
Looking at the solver testcase I see some cycles: cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-registration-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ----> cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-calendar-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ----> cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-manual-9.1.20090618-41.1.noarch ####> egroupware-epl-wiki-9.1.20090618-41.1.noarch ----> egroupware-epl-core-9.1.20090618-41.1.noarch ----> cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-manual-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ----> cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-bookmarks-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ----> cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-tracker-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ----> CYCLE: ----> egroupware-epl-9.1.20090618-41.1.noarch ====> egroupware-epl-core-9.1.20090618-41.1.noarch ####> ----> normal dependency ====> prereq dependency ####> broken dependency This was generated with the new transaction ordering code from the libsatsolver library. In 11.1, libzypp does the ordering. The zypper log contains: dependency loop: egroupware-epl -> egroupware-epl-core dependency loop: apache2-prefork -> apache2 dependency loop: egroupware-epl-egw-pear -> egroupware-epl-core dependency loop: egroupware-epl-wiki -> egroupware-epl-core dependency loop: egroupware-epl-emailadmin -> egroupware-epl-core dependency loop: egroupware-epl-sitemgr -> egroupware-epl-core dependency loop: egroupware-epl-filemanager -> egroupware-epl-core dependency loop: egroupware-epl-infolog -> egroupware-epl-core dependency loop: egroupware-epl-projectmanager -> egroupware-epl-core dependency loop: egroupware-epl-importexport -> egroupware-epl-core dependency loop: egroupware-epl-news_admin -> egroupware-epl-core dependency loop: egroupware-epl-stylite -> egroupware-epl-core dependency loop: egroupware-epl-notifications -> egroupware-epl-core dependency loop: egroupware-epl-phpsysinfo -> egroupware-epl-core dependency loop: egroupware-epl-developer_tools -> egroupware-epl-core dependency loop: egroupware-epl-felamimail -> egroupware-epl-core dependency loop: egroupware-epl-sambaadmin -> egroupware-epl-core dependency loop: egroupware-epl-phpbrain -> egroupware-epl-core dependency loop: egroupware-epl-syncml -> egroupware-epl-core dependency loop: egroupware-epl-timesheet -> egroupware-epl-core dependency loop: egroupware-epl-resources -> egroupware-epl-core dependency loop: egroupware-epl -> egroupware-epl-polls dependency loop: egroupware-epl-tracker -> egroupware-epl-core dependency loop: egroupware-epl-bookmarks -> egroupware-epl-core dependency loop: egroupware-epl-manual -> egroupware-epl-core dependency loop: egroupware-epl-calendar -> egroupware-epl-core dependency loop: egroupware-epl-registration -> egroupware-epl-core So it also sees the cycles. I'm not sure if it is clever enough to not break PreReqs if the cycle can be broken with normal Requires, though. I may be that it treats PreReqs like Reqs, which would be a bug. (Actually it's a packaging error from your side: A cycle containing a PreReq dependency is not installable. egroupware-epl PreReq: egroupware-epl-core means that egroupware-epl-core must be when egroupware-epl gets installed. Working means that all dependencies are fulfilled, but egroupware-epl-core requires egroupware-epl.) Nevertheless, it shouldn't break PreReq deps. The new libsatsolver code will not do this, it has computed the following order: install egroupware-epl-registration-9.1.20090618-41.1.noarch install egroupware-epl-calendar-9.1.20090618-41.1.noarch install egroupware-epl-manual-9.1.20090618-41.1.noarch install egroupware-epl-bookmarks-9.1.20090618-41.1.noarch install egroupware-epl-tracker-9.1.20090618-41.1.noarch install egroupware-epl-core-9.1.20090618-41.1.noarch install egroupware-epl-polls-9.1.20090618-41.1.noarch install egroupware-epl-projectmanager-9.1.20090618-41.1.noarch install egroupware-epl-wiki-9.1.20090618-41.1.noarch install egroupware-epl-stylite-9.1.20090618-41.1.noarch install egroupware-epl-developer_tools-9.1.20090618-41.1.noarch install egroupware-epl-sambaadmin-9.1.20090618-41.1.noarch install egroupware-epl-infolog-9.1.20090618-41.1.noarch install egroupware-epl-resources-9.1.20090618-41.1.noarch install egroupware-epl-news_admin-9.1.20090618-41.1.noarch install egroupware-epl-timesheet-9.1.20090618-41.1.noarch install egroupware-epl-phpsysinfo-9.1.20090618-41.1.noarch install egroupware-epl-notifications-9.1.20090618-41.1.noarch install egroupware-epl-egw-pear-9.1.20090618-41.1.noarch install egroupware-epl-phpbrain-9.1.20090618-41.1.noarch install egroupware-epl-sitemgr-9.1.20090618-41.1.noarch install egroupware-epl-importexport-9.1.20090618-41.1.noarch install egroupware-epl-filemanager-9.1.20090618-41.1.noarch install egroupware-epl-syncml-9.1.20090618-41.1.noarch install egroupware-epl-emailadmin-9.1.20090618-41.1.noarch install egroupware-epl-felamimail-9.1.20090618-41.1.noarch install egroupware-epl-9.1.20090618-41.1.noarch Michael Andres, any comments about the libzypp behaviour? 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
Hi Michael, thanks for your help :-) We were not aware of a (circular) dependency from egroupware-epl-core to egroupware-epl, as this was never explicitly specified in our spec file. It was caused by a compatibility/workaround for suse: to be able to start cli scripts with #!/usr/bin/php we created a symlink from /usr/bin/php --> /usr/bin/php5 and that was created in egroupware-epl and only implicitly required by rpm analysing the script interpreter. Anyway thanks for pointing in the right direction :-) Ralf Michael Schroeder schrieb:
On Thu, Jun 25, 2009 at 12:42:11PM +0200, Ralf Becker wrote:
I'm building rpm packages for EGroupware (www.egroupware.org). They have a "metapackage" requiring the default modules and then executing a post_install script (create database, install EGroupware and all modules via a comand line client). All modules depend of a core module, which is also required by the metapackage and which includes the post-install script itself. (That way you can use the metapackage for convenience, but you can also install the single packages, if you want to).
What I expect would be the following behaviour:
1. Install required packages (including required core package) 2. Install metapackage 3. Execute post install of metapackage
(That's eg. the behaviour of yum or aptitude).
Looking at the solver testcase I see some cycles:
cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-registration-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ---->
cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-calendar-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ---->
cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-manual-9.1.20090618-41.1.noarch ####> egroupware-epl-wiki-9.1.20090618-41.1.noarch ----> egroupware-epl-core-9.1.20090618-41.1.noarch ---->
cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-manual-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ---->
cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-bookmarks-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ---->
cycle: ----> egroupware-epl-9.1.20090618-41.1.noarch ----> egroupware-epl-tracker-9.1.20090618-41.1.noarch ####> egroupware-epl-core-9.1.20090618-41.1.noarch ---->
CYCLE: ----> egroupware-epl-9.1.20090618-41.1.noarch ====> egroupware-epl-core-9.1.20090618-41.1.noarch ####>
----> normal dependency ====> prereq dependency ####> broken dependency
This was generated with the new transaction ordering code from the libsatsolver library. In 11.1, libzypp does the ordering.
The zypper log contains:
dependency loop: egroupware-epl -> egroupware-epl-core dependency loop: apache2-prefork -> apache2 dependency loop: egroupware-epl-egw-pear -> egroupware-epl-core dependency loop: egroupware-epl-wiki -> egroupware-epl-core dependency loop: egroupware-epl-emailadmin -> egroupware-epl-core dependency loop: egroupware-epl-sitemgr -> egroupware-epl-core dependency loop: egroupware-epl-filemanager -> egroupware-epl-core dependency loop: egroupware-epl-infolog -> egroupware-epl-core dependency loop: egroupware-epl-projectmanager -> egroupware-epl-core dependency loop: egroupware-epl-importexport -> egroupware-epl-core dependency loop: egroupware-epl-news_admin -> egroupware-epl-core dependency loop: egroupware-epl-stylite -> egroupware-epl-core dependency loop: egroupware-epl-notifications -> egroupware-epl-core dependency loop: egroupware-epl-phpsysinfo -> egroupware-epl-core dependency loop: egroupware-epl-developer_tools -> egroupware-epl-core dependency loop: egroupware-epl-felamimail -> egroupware-epl-core dependency loop: egroupware-epl-sambaadmin -> egroupware-epl-core dependency loop: egroupware-epl-phpbrain -> egroupware-epl-core dependency loop: egroupware-epl-syncml -> egroupware-epl-core dependency loop: egroupware-epl-timesheet -> egroupware-epl-core dependency loop: egroupware-epl-resources -> egroupware-epl-core dependency loop: egroupware-epl -> egroupware-epl-polls dependency loop: egroupware-epl-tracker -> egroupware-epl-core dependency loop: egroupware-epl-bookmarks -> egroupware-epl-core dependency loop: egroupware-epl-manual -> egroupware-epl-core dependency loop: egroupware-epl-calendar -> egroupware-epl-core dependency loop: egroupware-epl-registration -> egroupware-epl-core
So it also sees the cycles. I'm not sure if it is clever enough to not break PreReqs if the cycle can be broken with normal Requires, though. I may be that it treats PreReqs like Reqs, which would be a bug.
(Actually it's a packaging error from your side: A cycle containing a PreReq dependency is not installable. egroupware-epl PreReq: egroupware-epl-core means that egroupware-epl-core must be when egroupware-epl gets installed. Working means that all dependencies are fulfilled, but egroupware-epl-core requires egroupware-epl.)
Nevertheless, it shouldn't break PreReq deps. The new libsatsolver code will not do this, it has computed the following order:
install egroupware-epl-registration-9.1.20090618-41.1.noarch install egroupware-epl-calendar-9.1.20090618-41.1.noarch install egroupware-epl-manual-9.1.20090618-41.1.noarch install egroupware-epl-bookmarks-9.1.20090618-41.1.noarch install egroupware-epl-tracker-9.1.20090618-41.1.noarch install egroupware-epl-core-9.1.20090618-41.1.noarch install egroupware-epl-polls-9.1.20090618-41.1.noarch install egroupware-epl-projectmanager-9.1.20090618-41.1.noarch install egroupware-epl-wiki-9.1.20090618-41.1.noarch install egroupware-epl-stylite-9.1.20090618-41.1.noarch install egroupware-epl-developer_tools-9.1.20090618-41.1.noarch install egroupware-epl-sambaadmin-9.1.20090618-41.1.noarch install egroupware-epl-infolog-9.1.20090618-41.1.noarch install egroupware-epl-resources-9.1.20090618-41.1.noarch install egroupware-epl-news_admin-9.1.20090618-41.1.noarch install egroupware-epl-timesheet-9.1.20090618-41.1.noarch install egroupware-epl-phpsysinfo-9.1.20090618-41.1.noarch install egroupware-epl-notifications-9.1.20090618-41.1.noarch install egroupware-epl-egw-pear-9.1.20090618-41.1.noarch install egroupware-epl-phpbrain-9.1.20090618-41.1.noarch install egroupware-epl-sitemgr-9.1.20090618-41.1.noarch install egroupware-epl-importexport-9.1.20090618-41.1.noarch install egroupware-epl-filemanager-9.1.20090618-41.1.noarch install egroupware-epl-syncml-9.1.20090618-41.1.noarch install egroupware-epl-emailadmin-9.1.20090618-41.1.noarch install egroupware-epl-felamimail-9.1.20090618-41.1.noarch install egroupware-epl-9.1.20090618-41.1.noarch
Michael Andres, any comments about the libzypp behaviour?
Cheers, Michael.
-- Ralf Becker Director Software Development Stylite GmbH [open style of IT] Morschheimer Strasse 15 67292 Kirchheimbolanden fon +49 (0) 6352 70629-0 fax +49 (0) 6352 70629-30 mailto: rb@stylite.de www.stylite.de www.egroupware.org ________________________________________________ Geschäftsführer Andre Keller, Gudrun Müller, Nigel Vickers und Ralf Becker Registergericht Kaiserslautern HRB 30575 Umsatzsteuer-Id / VAT-Id: DE214280951 -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
On Thursday 25 June 2009 19:02:18 Michael Schroeder wrote:
Michael Andres, any comments about the libzypp behaviour?
The 11.1 code is not able to do this detailed cycle analysis, so it splits the cycle somewhere. Trying to fix this required rewriting the ordering code. That's why I was waiting for the new satsolver transaction ordering. I'm currently about to adapt libzypp for Factory to use it. If we can backport the satsolver code to 11.1, we could fix zypp to use it there as well. Until this happes, the package dependencies have to be fixed. -- cu, Michael Andres +------------------------------------------------------------------+ Key fingerprint = 2DFA 5D73 18B1 E7EF A862 27AC 3FB8 9E3A 27C6 B0E4 +------------------------------------------------------------------+ Michael Andres YaST Development ma@novell.com SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) Maxfeldstrasse 5, D-90409 Nuernberg, Germany, ++49 (0)911 - 740 53-0 +------------------------------------------------------------------+ -- To unsubscribe, e-mail: zypp-devel+unsubscribe@opensuse.org For additional commands, e-mail: zypp-devel+help@opensuse.org
participants (3)
-
Michael Andres -
Michael Schroeder -
Ralf Becker