On 11/12/2011 10:11 AM, Kevin Ottens wrote:
On Saturday 12 November 2011 01:01:15 Valentin Rusu wrote:
As you may already know, the ksecretsservice API merging to the
kdelibs/4.7 branch was no longer an acceptable solution because of
recent frameworks related decisions. It was suggested to put it into
it's separate repository, alongside with the
kde-runtime/ksecretsserviced I also merged yesterday.
After thinking twice, I'd like to bring these components into the
kdeutils/ksecrets repository.
Are you ok with this?
Sounds like a bad idea to me because...
A possible issue if that's ok for you: the kdeutils/kwallet will depend
on this repository and it contains guard code to exclude
ksecretsservice-related code if qca not found - that will be extended to
the case ksecrets repository will not be found. This raises the problem
of module dependencies: kdelibs needs to be built first, but if ksecrets
was not compiled first, the required headers will not be there and as
such kwallet will not have the ksecretsservice-related code.
That looks like a circular reference :-)
... it creates this type of situation.
Any particular reason why you didn't stick to the separate repo solution as
proposed earlier? For some reason I fail to see what motivated your change on
that.
Well, as I explained in other threads, the initial decision I understood
was to have the components in kdelibs and kde-runtime then. And I did
stick with that. Please see my response to Aaron.
--
Valentin Rusu (IRC valir, KDE vrusu)
KSecretsService (former KSecretService, KWallet replacement)
