[Freeipa-devel] Fedora 20 Release

[Rich Megginson]

On 12/16/2013 09:33 AM, Alexander Bokovoy wrote:
> 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.

Why?

>
>
>>> 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.
>