[Freeipa-devel] Fedora 20 Release

[Alexander Bokovoy]

On Mon, 16 Dec 2013, Rich Megginson wrote:
>On 12/16/2013 09:21 AM, Alexander Bokovoy wrote:
>>On Mon, 16 Dec 2013, Rich Megginson wrote:
>>>On 12/16/2013 08:07 AM, Petr Spacek wrote:
>>>>Hello list,
>>>>
>>>>we have to decide what we will do with 389-ds-base package in 
>>>>Fedora 20.
>>>>
>>>>Currently, we know about following problems:
>>>>
>>>>Schema problems:
>>>>  https://fedorahosted.org/389/ticket/47631 (regression)
>>>
>>>Fixed.
>>>
>>>>
>>>>Referential Integrity:
>>>>  https://fedorahosted.org/389/ticket/47621 (new functionality)
>>>
>>>Does it matter if new functionality is a problem?
>>Only if there is a crash.
>
>I don't think there is a crash here.
>
>>
>>>
>>>>https://fedorahosted.org/389/ticket/47624 (regression)
>>>>
>>>>Replication:
>>>>  https://fedorahosted.org/389/ticket/47632 (?)
>>>>
>>>>Stability:
>>>>  https://bugzilla.redhat.com/show_bug.cgi?id=1041732
>>>
>>>Fixed.  However, there is a problem with slapi-nis: 
>>>https://bugzilla.redhat.com/show_bug.cgi?id=1043546
>>slapi-nis part seems to be a double-free on plugin shutdown.
>>I'll look into it tomorrow morning if Nalin will not find it earlier.
>>
>>
>>>>https://fedorahosted.org/389/ticket/47629 (we are not sure if 
>>>>the syncrepl really plays some role or not)
>>>
>>>How can we find out?
>>>
>>>>
>>>>One option is to fix 1.3.2.x as quickly as possible.
>>>>
>>>>Another option is to build 1.3.1.x for F20 with Epoch == 1 and 
>>>>release it as quickly as possible.
>>>>
>>>>The problem with downgrade to 1.3.1.x is that it requires 
>>>>manual change in dse.ldif file. You have to disable 'content 
>>>>synchronization' (syncrepl) and 'whoami' plugins which are not 
>>>>in 1.3.1.x packages but were added and enabled by 1.3.2.x 
>>>>packages.
>>>>
>>>>In our tests, the downgraded DS server starts and works after 
>>>>manual dse.ldif correction (but be careful - we didn't test 
>>>>replication).
>>>>
>>>>Here is the main problem:
>>>>389-ds-base 1.3.2.8 is baked to Fedora 20 ISO images and there 
>>>>is not way how to replace it there. It means that somebody can 
>>>>do F19->F20 upgrade from ISO and *then* upgrade from repos will 
>>>>break his DS configuration (because of new plugins...).
>>>>
>>>>Simo thinks that this is a reason why 'downgrade package' with 
>>>>1.3.1.x inevitably needs automated script which will purge two 
>>>>missing plugins from dse.ldif.
>>>
>>>We have an upgrade/downgrade framework, it should be easy to 
>>>disable/remove these plugins.
>>>
>>>Is that it?  Are there any other problems found attempting to 
>>>downgrade 1.3.2 to 1.3.1 in F20?
>>Packaging issue -- epoch will have to be increased and maintained
>>forever. It is weird but that's what it is.
>
>Sure.  But that's a one time thing.  And, it's only for F20 - once we 
>go to F21, we can remove the epoch.
No, and that's key here. Once Epoch is in place, it is forever.


>>And then making sure
>>disabling the plugins will happen only on downgrade, this is actually an
>>RPM trigger which is something people easily get wrong.
>
>I think it's simpler than that - if the version is 1.3.1, 
>disable/remove the plugins.  If the version is 1.3.2, add/enable the 
>plugins.  I don't think this will be a big deal.
Ok, fine.

-- 
/ Alexander Bokovoy