(purging some off topic bits ;)) On 10/13/2010 10:12 AM, Vladislav Bogdanov wrote: > >>> 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.
I think the main difference is that some of those libraries are capable of providing services without the daemon running. Something that´s not true for all packages. Let´s put aside for a minute the build/linking case that used to be a problem many years ago, where maintaining build machine was expensive (tho I understand it, let´s be clear). > >>>> 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). I don´t remember exactly the detail here (I´d have to test it myself), but let´s assume we do those changes in sync, how does "yum install pacemaker" behave? Would pull in both corosync and heartbeat? or it will force the user to select one? Without repeating myself too much, default should install both IMHO and expert users can then drop the core they do not want. (and yes, let´s avoid the whole Conflicts/Obsoletes thingy as we are trying to play nicely with each other ;)) Fabio _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
