[Freeipa-devel] FreeIPA server package group

Rob Crittenden rcritten at redhat.com
Fri Sep 6 13:05:38 UTC 2013


Martin Kosek wrote:
> On 09/05/2013 07:50 PM, Rob Crittenden wrote:
>> Martin Kosek wrote:
>>> On 08/29/2013 12:22 PM, Tomas Babej wrote:
>>>> On 08/29/2013 11:55 AM, Petr Viktorin wrote:
>>>>> On 08/28/2013 12:20 PM, Tomas Babej wrote:
>>>>>> On 08/28/2013 12:03 PM, Petr Viktorin wrote:
>>>>>>> On 08/28/2013 11:46 AM, Tomas Babej wrote:
>>>>>>>> On 08/26/2013 10:14 AM, Tomas Babej wrote:
>>>>>>>>> On Mon 26 Aug 2013 10:12:09 AM CEST, Petr Vobornik wrote:
>>>>>>>>>> On 08/26/2013 09:54 AM, Tomas Babej wrote:
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>> I cooked up a patch for comps that adds a FreeIPA package group.
>>>>>>>>>>>
>>>>>>>>>>> Please chime in if you're OK with package selection / description.
>>>>>>>>>>>
>>>>>>>>>>> For illustration, see the attached image. FreeIPA will be added as an
>>>>>>>>>>> add-on in an installer under the Infrastructure server environment,
>>>>>>>>>>> that means, in the included images it will be at the same level
>>>>>>>>>>> as DNS or FTP server.
>>>>>>>>>>>
>>>>>>>>>>> It will also appear in the Software Selection tool (PackageKit).
>>>>>>>>>>>
>>>>>>>>>>> It should also be available under as yum groupinstall "FreeIPA
>>>>>>>>>>> server",
>>>>>>>>>>> and in PackageKit, as I understand comps is also source for that too.
>>>>>>>>>>>
>>>>>>>>>>> https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/3630
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> IMO the Audit part in the description is false advertisement. Same
>>>>>>>>>> issue is in package descriptions.
>>>>>>>>>
>>>>>>>>> I know, it's taken directly from there.
>>>>>>>>>
>>>>>>>>> I'd rather have it consistent, if we're going to change it here, we
>>>>>>>>> should do
>>>>>>>>> there too, so that we do not end up with multiple (seemingly
>>>>>>>>> incomplete)
>>>>>>>>> descriptions at various places.
>>>>>>>>
>>>>>>>> Anybody else does have any other concerns? We need to move with this
>>>>>>>> effort since string freeze for F20 is coming.
>>>>>>>>
>>>>>>>> I'm particulary dubious about including the freeipa-tests package.
>>>>>>>
>>>>>>> I don't think that should be included, developer tests are unnecessary
>>>>>>> for a server.
>>>>>>>
>>>>>> It was marked as optional in the initial proposal, but I agree it's
>>>>>> unnecessary for
>>>>>> it to be there at all.
>>>>>>>> We discussed the A (as Audit) part in the description with Rob. The
>>>>>>>> fact is
>>>>>>>> that this is taken from the freeipa-server package description and
>>>>>>>> nobody
>>>>>>>> complained in 7 years.
>>>>>>>
>>>>>>
>>>>>> Updated tests attached.
>>>>>>
>>>>>
>>>>> Oh, one more thing I remembered just now -- is it too late?
>>>>> We should include bind-dyndb-ldap (which pulls in bind). Preferably as
>>>>> default.
>>>>>
>>>>
>>>> I included it there.
>>>>
>>>> If anyone else wants to chime in, please do now, I'll create a ticket with
>>>> rel-eng at the end of the day.
>>>>
>>>
>>> Thanks for this effort. What is the status of the bug - did you create the
>>> request already?
>>>
>>> We will need to do one more change and remove freeipa-server-strict package as
>>> up on the decision on today's developer meeting we decided to drop this
>>> subpackage in Fedora 20 and later and depend on our new FreeIPA Continuous
>>> Integration system instead.
>>
>> I missed that meeting so maybe I'm re-hashing things, but I don't see how CI
>> solves the problem that the strict subpackage does. Sure, it won't be as much a
>> surprise to us when other packages are updated, but this doesn't prevent a user
>> from also updating to the package. The strict package prevents upgrade until
>> we've confirmed that things are actually working. CI does not.
>
> CI should prevent problems at the begging, before they happen - right when the
> new Dogtag/Kerberos/389-ds-base is in updates-testing. That gives a change to
> give negative Karma and have that package fixed before it hits stable updates.
>
> IMO freeipa-server-strict subpackage is too heavy weight and does not provide
> the benefit we would want. So far, IMHO, it was rather a burden for maintainers
> and broke quite frequently.

I'm not a huge fan of the strict package, I resisted it for a long time. 
But it does serve its intended purpose: stability for users. I agree it 
is a pain, particularly in rawhide.

I guess I'm just not convinced that CI is going to catch everything.

rob




More information about the Freeipa-devel mailing list