On 10/13/2010 6:52 AM, Vladislav Bogdanov wrote: > 13.10.2010 07:14, Fabio M. Di NItto wrote: >> On 10/13/2010 12:14 AM, Vadym Chepkov wrote: >> >>>> Also you might want to notice that there is no way any of the corosync >>>> library can be of any use on a system without corosync main package. >>> >>> Of cause there is. What if you just compile pacemaker, for instance? >>> Why would you need to install corosync daemon to just link pacemaker binary? >>> >> >> So you are telling me that your build machine doesn't have a few MB of >> harddisk to install corosync rpm? If that's the problem you are trying >> to solve, I think you have some other issues to solve first, because in >> that condition, you will likely be unable to apply any security updates >> to any of the other packages. >> >> and as I explained in another email in this thread, we do have the exact >> same issue for users of pacemaker with corosync that finds themselves >> installing heartbeat. The major difference is that we do acknowledge the >> reason why is done that way and live with it. Life goes on. >> >> Pacemaker, is one of the few pieces of software that links against 2 >> competitive "cores". It is cool enough to add support for both at the >> price of a few extra MB of harddisk used on the final system, with the >> benefit that everything users might want, works out of the box. > > Offtopic: This reminds me installation of thunderbird on netbook with > 8Gb flash. It has (had?) dependency on gnome-vfs library which in turn > pulled whole gnome to disk.
Offtopic^2: Be careful, that I never said that the dependency chain, as required by fedora is perfect. I come from a Debian background where each lib is in its own package (you get the idea) :) All I am saying is that the chain, as expressed now, allow users to get a fully functional system, and in this specific case, with the option to select the core they want without caring too much about packages layout. > > I already wrote that on pacemaker list, "-libs" is generally not a > subpackage, but rather a "superpackage". If libraries are in base > package then dependency of subpackages on base package is correct > (automatic BTW). If corosync package contains libraries, and > corosync-daemons contains daemon, initscript etc., then this is correct > too. But not if libraries splitted to a subpackage (IMHO). Well they are considered subpackages by many (if not all) distros, changing that kind of mindset won´t start from here :) > >> >> So let's assume both heartbeat and corosync drops that Require lines, I >> am willing to bet in a matter of a week or two, somebody is going to >> report that installing pacemaker doesn't install required dependencies >> on corosync or heartbeat. > > This is usually solved by "virtual" dependencies. If both corosync and > heartbeat have "Provides: cluster-engine" and pacemaker has "Requires: > cluster-engine" then everything will go smooth. It won´t solve the problem because pacemaker still links with both -libs and those will pull in both daemons. Unless some more surgery is done by dropping -libs Requires: base-package, both daemons will Provide: cluster-engine and pacemaker will Require: cluster-engine. In order to drop the Requires: base-package, we might have to ask exceptions (at least for corosync since the libraries are not functional without the daemon and it doesn´t make a lot of sense). Assuming we even want to go through that expensive (time wise and coordination at least) route, it will leave the users with a thought choice to make right from "yum install" step to decide what core to use and understand package layout from day 0. IMHO, given that clustering is already not very super user-friendly, I don´t really feel the urgent need to impose that on users immediately, specially when the cost to allow the change in future is only a few MB of harddisk space and one package installed (either that being corosync or heartbeat, I am looking at it in both directions). Fabio _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
