[csw-maintainers] OpenSSL project task order

Dagobert Michelsen dam at opencsw.org
Wed Jun 20 12:14:02 CEST 2012


Hi Yann,

Am 20.06.2012 um 11:43 schrieb Yann Rouillard:
> 2012/6/20 Dagobert Michelsen <dam at opencsw.org>
>> you carefully splitted the tasks into different groups in
>>  http://wiki.opencsw.org/project-openssl
>> 
>> Which order would you recommend?
> 
> There are no order to follow between groups, they are independant.
> There are no order inside groups, they just must be released together (except if one program refuse to compile because one of its dependancy is still linked with openssl 0.9.8, I am not aware if that can happens).
> 
> For exemple, you can't release gnomesysmon and courier_imap separately, because gnomesysmon is linked several times with openssl at runtime: directly and indirectly by the way of a dependancy on libldap2_4_2.
> 
> So you need to recompile both gnomesysmon and libldap2_4_2 at the same time to avoid a runtime linking with both version.
> 
> But as courier_imap is also directly linked with openssl and indirectly linked through libldap2_4_2, you also need to recompile courier_imap at the same time to avoid to create a new dual runtime linking situation with courier_imap.
> 
> As said before, it would be helpful to know when the dual runtime linking is really a problem, this would maybe help to significantly simplify the coordination work. 
> 
> Does someone know what happens exactly when a program is linked with two different libraries at runtime by the way of one of its dependancy ?

The worst thing would be having two sets of global variables saving state for the different
versions.

>> Can I talk you into taking the stab at project
>> lead and ask people to do specific things?
> 
> Yes, I intented to do it but I will not be able to do it until next week.

Cool, NP.

> The fact that some maintainers are retired will make things complicated. I've some seen mails about stopping to support desktop apps. Is there some consensus about this ? That would remove a lot of unmaintained packages from group 1.

If it is a problem and nobody is willing to take it over they will be dropped.

> Some of these packages may even not lack a GAR recipe, don't they ?

Most certainly the orphaned ones do not have a GAR recipe.

> (BTW, I am not sure we should even keep packages that are not maintained anymore. At best, it may be a good idea to move them to a separate catalog)

This is exactly what we have planned for the "Kiel"-release:
  http://wiki.opencsw.org/package-tiering
  http://wiki.opencsw.org/release-kiel
 
>> What should I do first from that list?
> 
> I would recommend to first work on group 1 because this is the biggest group and one missing updated package prevents all the other to be updated. 

Ok.


Best regards

  -- Dago

-- 
"You don't become great by trying to be great, you become great by wanting to do something,
and then doing it so hard that you become great in the process." - xkcd #896



More information about the maintainers mailing list