On 11/12/2011 11:24 AM, Kevin Ottens wrote:
Please see my response to Aaron.
And that's where my question comes from, I thought the consensus with the
involved parties after that new discussion was for a new repository, but I
might have missed something.
Well, the discussion came *after* I merged the code in kdelibs, despite
the messages I posted before that, that's what it's missing :-)
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.
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.
--
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)
