[ClusterLabs Developers] Impact of changing Pacemaker daemon names on other projects?

Jan Pokorný jpokorny at redhat.com
Mon Apr 16 11:40:38 EDT 2018

On 16/04/18 14:32 +0200, Klaus Wenninger wrote:
> On 04/16/2018 01:52 PM, Jan Pokorný wrote:
>> On 29/03/18 11:13 -0500, Ken Gaillot wrote:
>>> 4. Public API symbols: for example, crm_meta_name() ->
>>> pcmk_meta_name(). This would be a huge project with huge impact, and
>>> will definitely not be done for 2.0.0. We would immediately start using
>>> the new convention for new API symbols, and more slowly update existing
>>> ones (with compatibility wrappers for the old names).
>> Value added here would be putting some commitment behind the "true
>> public API" when the symbols get sifted carefully, leaving some other
>> naming prefixes reserved for private only ones (without any commitment
>> whatsoever).
> Like e.g. pcmk_* & pcmkpriv_*  (preferably something shorter
> for the latter) ?

Yes, something like that (pcmk_* vs. anything not starting with "pcmk_"
might suffice), which would allow for compiling library(ies) twice
-- once for public use (only "public API" symbols visible), once
for pacemaker's own usage (libpcmk_foo_private.so, everything non-static
visible).  That might be a first step towards something supportable,
start with literally nothing in the public version, gradually grow the
numbers, with almost no hassle other than adding symbols to an external
list and/or renaming formerly private-only symbols so as to match the
regexp/glob.  All native executables would naturaly link against
libpcmk_foo_private versions.  Later on, these can be merged or
otherwise restructured.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20180416/6fb5a1ce/attachment-0002.sig>

More information about the Developers mailing list