13.10.2010 09:58, Fabio M. Di Nitto wrote: ... >>> 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.
Offtopic^3: Just imagine: fedora-everything-23-1.x86_64.rpm :) >> 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 :) Yes, formally they are. OK, Let's wait for the answer from guidelines maintainer... Majority of fedora "-libs" packages do not require base package (I checked that), so that simply could be an incompleteness of guidelines. >>> 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. That is exactly what I meant. > 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. It is absolutely legal to have both heartbeat and corosync packages installed even with that "Provides: cluster-engine" virtual dependencies as long as they do not have "Conflicts:" or "Obsoletes:" on each other or some filesystem-level conflicts. So, each of them could be added later (or removed as long as another remains installed). > 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
