[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