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

Valentin Rusu kde at rusu.info
Mon Nov 14 20:42:27 GMT 2011


On 11/14/2011 06:04 PM, Kevin Ottens wrote:
> On Saturday 12 November 2011 11:35:22 Valentin Rusu wrote:
>> 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;

The libs part would lead to a Tier2 library - I expected that and your 
other mail confirms it.
May it contain the other ksecretsservice components such as the deamon 
and the sync tool (those who are already under kdeutils)?
Depending on this answer, I'll either move the libs inside 
kdeutils/ksecrets or request a new git repo.

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

No problem, I like the idea of a plug-in. It's better suited to this 
case and I should have thought of it from the start.

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

Indeed.

>
> Hope that helps solve the situation.

Yes, it solves it quite right, thanks very much.


-- 
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)





More information about the kde-core-devel mailing list