[proposal] Move all of the ksecretsservice components into kdeutils/ksecrets

Kevin Ottens ervin at kde.org
Mon Nov 14 17:04:08 UTC 2011


On Saturday 12 November 2011 11:35:22 Valentin Rusu wrote:
> On 11/12/2011 11:24 AM, Kevin Ottens wrote:
> > So that was the intent of my previous email, now that the red flag got
> > raised for inclusion in kdelibs master, why not going for a separate
> > repository?
> That's exactly what I'm doing now. I'm only searching for the good location.
> > At least contrary to inclusion in kdeutils it would avoid the circular
> > dependency issue.
> 
> Well, ksecrets is already a separate repository and it's located under
> the kdeutil parent classification.

Right but I had more in mind the lib parts.

> And the circular dependency will be there as long as kdecore (where
> KCompositeJob lives) and kdeui (where KWallet lives) are tied together.
> Here is the schema :
> - KWallet legacy code *needs* KSecretsService API that *needs*
> KCompositeJob ;
> - if KSecretsServiceAPI is not present, then exclude KWallet specific
> code, so KSecretsService API should be compiled first, but that requires
> KCompositeJob.

OK, so the only proper way out I see from here would be the following:
 * Reverting your changes in kdelibs 4.7 branch, the whole lot is definitely 
not material for 4.7.4 IMO;
 * Moving the libs part in your repository with the rest of ksecretservices to 
keep it all together;
 * Introducing a plugin loading approach inside of the KWallet convenience API
 * Make your current code for the KWallet convenience API a plugin for the 
above mechanism (seeing your code right now, it'll even map fairly well as in 
most places it's right now "if (m_secretServices)" else it uses the old code 
path) and have this plugin installed at the same time than your library.

I know it's a bit of extra work now and I'm sorry about that. That said, this 
compromise comes with the longer term advantage that with such an organization 
you're pretty much ready for the KDE Frameworks time, it'll mainly be about 
extra QA from there, but you won't need to re-split later (which will be the 
case in the KDE Frameworks world). It also allows you to release along KDE SC 
4.8 with kdeutils.

Hope that helps solve the situation.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud patron of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-utils-devel/attachments/20111114/ba6a7ecb/attachment.sig>


More information about the Kde-utils-devel mailing list