Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/14/2011 09:19 PM, Aaron J. Seigo wrote: Valentin: please let me know when ksecretservice is in its own repo, I just removed ksecretsservice from kdelibs and kde-runtime. Next move will be inclusion in ksecrets repository. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday, November 14, 2011 21:43:12 Valentin Rusu wrote: > What would be the current "beautiful" plug-in implementation to take as an > example? there are some tutorials here: http://techbase.kde.org/Development/Tutorials#Services:_Applications_and_Plugins this one gets right to it: http://techbase.kde.org/Development/Tutorials/Services/Plugins there are many practical examples in KDE as well; libplasma has half a dozen different types of plugins, in fact :) feel free to ask questions or track me down on irc if you need/want any input... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday 14 November 2011 21:42:27 Valentin Rusu wrote: > 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. Yes, you can reuse the same repository IMO. > > Hope that helps solve the situation. > > Yes, it solves it quite right, thanks very much. Excellent! Thanks for your patience! Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
Kevin Ottens wrote: > * 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. Plugin mechanisms to provide essential functionality really suck for packaging. It means the dependencies no longer get autodetected by RPM and we have to manually add Requires for all the stuff to get actually working applications. See e.g.: https://bugzilla.redhat.com/show_bug.cgi?id=73 for an example. (In that case, the problem is KTextEditor, which is in kdelibs, but the actual implementation is in the kate tarball.) Kevin Kofler
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/14/2011 09:19 PM, Aaron J. Seigo wrote: On Monday, November 14, 2011 18:04:08 Kevin Ottens wrote: > * 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. as a mea culpa, if Valentin is OK with it, i volunteer to write the plugin support. Ok, the mea culpa is enough for me :-) I prefer writing the plug-in myself, as I need to master this technique too. What would be the current "beautiful" plug-in implementation to take as an example? Valentin: please let me know when ksecretservice is in its own repo, and i'll take care of the kwallet integration ... technically it's a new feature that'll be dropping into 4.8's kdelibs, but it's a reasonable compromise imho. Ok, works for me. i will commit it after the 4.7.4 release so as not to interfere with that. Ok, I'll commit that after 4.7.4. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
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)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday, November 14, 2011 18:04:08 Kevin Ottens wrote: > * 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. as a mea culpa, if Valentin is OK with it, i volunteer to write the plugin support. Valentin: please let me know when ksecretservice is in its own repo, and i'll take care of the kwallet integration ... technically it's a new feature that'll be dropping into 4.8's kdelibs, but it's a reasonable compromise imho. i will commit it after the 4.7.4 release so as not to interfere with that. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday, 2011-11-14, Kevin Ottens wrote: > Right. Although I don't expect a kdeui to still exist in the end. The > relevant KWallet code might end up in a kde4support I think. For that to > happen we'd need a similar convenience API in libksecretservice itself if > deemed appropriate (the whole KWallet API being synchronous it makes me > feel a bit uneasy about it, could block on the other process, I'd rather > keep that explicit on the API consumer with exec'ed jobs). Definitely. But not because it could block but because it must block. And the only safe way to do that is to run the asynchronous call in a separate thread, blocking the calling thread with a semaphore or waitcondition. Loads of extra work for the maintainer of the synchronous wrapper for little extra convenience of the API using developer. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Monday 14 November 2011 06:48:50 Aaron J. Seigo wrote: > On Saturday, November 12, 2011 13:38:47 Valentin Rusu wrote: > > Ok, I'll then move it somewhere else. I'm very tempted by the kdecore > > module, the place where it's main dependency, KCompositeJob, lives. > > > > But I think the best place would be the *experimental* module. Ok for > > that? > if this indeed goes into the kdelibs frameworks branch, then it should go > into tier2/ksecretservice. (it depends on tier 1 libs, Yes, it'll likely depend on kcoreaddons in the end. > so is a tier 2 lib.) Correct. It'll be a "Tier 2 Integration Qt Addon" (depends on Tier 1 library + runtime dependency). > kdeui would be built after tier2/ksecretservice and link against the secret > service lib. Right. Although I don't expect a kdeui to still exist in the end. The relevant KWallet code might end up in a kde4support I think. For that to happen we'd need a similar convenience API in libksecretservice itself if deemed appropriate (the whole KWallet API being synchronous it makes me feel a bit uneasy about it, could block on the other process, I'd rather keep that explicit on the API consumer with exec'ed jobs). > this would give us zero circular dependencies, no excessive moving around of > things and it would be easy to break it into its own repo when that time > comes using git filter-branch. See my other email, I think it could and should be split right away so Valentin will be already in a very good position for KDE Frameworks. It's kinda odd to merge something in a repository we want to split anyway. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
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 signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Saturday, November 12, 2011 13:38:47 Valentin Rusu wrote: > Ok, I'll then move it somewhere else. I'm very tempted by the kdecore > module, the place where it's main dependency, KCompositeJob, lives. > > But I think the best place would be the *experimental* module. Ok for that? if this indeed goes into the kdelibs frameworks branch, then it should go into tier2/ksecretservice. (it depends on tier 1 libs, so is a tier 2 lib.) kdeui would be built after tier2/ksecretservice and link against the secret service lib. this would give us zero circular dependencies, no excessive moving around of things and it would be easy to break it into its own repo when that time comes using git filter-branch. Kevin Ottens: can you confirm the above as being in line with the tier structure? -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
Sebastian Kügler wrote: > On Saturday, November 12, 2011 08:12:27 Kevin Kofler wrote: >> All this stuff is going to make things much more work for us packagers >> (just like the separate kactivities), for no good reason other than some >> arbitrary "we froze kdelibs" decision! > > Calling it an arbitrary decision shows either of two things: you ignore > the rationale behind it, or you don't understand it. It's true that I don't understand the rationale behind the freeze, and never will. It just doesn't make sense. Developing for the future needs to be done in parallel to developing for the present, not at its expense. Note that I do understand the rationale about Frameworks 5 to some extent, though I'll admit that I'm not enthousiastic about yet another major binary- incompatible version and that I'm worried about the undesired side effects of reducing dependencies (from a quick look at the current frameworks branch: lost features (e.g. tilde expansion in KUrl), lost consistency (e.g. use of QFileDialog rather than KFileDialog, and last I checked QFileDialog only supported native dialogs with the static methods, so when you construct a QFileDialog object, you'll get the ugly Qt-only one), possible code duplication to avoid a dependency (not seen in frameworks yet, but I've seen this elsewhere and am worried that it might happen in frameworks too, especially when you'll try to actually fix that code you just "#if 0"ed without readding the dependency)). It's the freeze of kdelibs 4.x I have a problem with, not Frameworks 5 per se. > Frameworks 5 was a very conscious decision taken by the people, who by all > reasonable means are in the position to do so, and so was freezing > kdelibs. I understand you're not happy with this decision, and I'm sure by > now everybody else knows that, too -- no need to repeat it over and over > again without any added value. People are actually getting tired of it. And I'm getting tired of seeing issue after issue pop up here, all caused by that freeze, and the obvious solution to the issues getting summarily rejected. Am I really alone in that? :-( > Stating the bleeding obvious, if you want to get kdelibs (or its > successor) open to feature additions, help getting F5 ready, don't make it > take longer. If I didn't care about the long term, why would I have removed all the remaining Qt3Support and kde3support usage from Kompare recently? See for yourself: http://websvn.kde.org/trunk/KDE/kdesdk/kompare/?view=log What I don't see is why the long-term development needs to happen at the expense of short-term development. Kevin Kofler
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Saturday, November 12, 2011 08:12:27 Kevin Kofler wrote: > All this stuff is going to make things much more work for us packagers > (just like the separate kactivities), for no good reason other than some > arbitrary "we froze kdelibs" decision! Calling it an arbitrary decision shows either of two things: you ignore the rationale behind it, or you don't understand it. Please fix the applicable problem(s) in your emails. Frameworks 5 was a very conscious decision taken by the people, who by all reasonable means are in the position to do so, and so was freezing kdelibs. I understand you're not happy with this decision, and I'm sure by now everybody else knows that, too -- no need to repeat it over and over again without any added value. People are actually getting tired of it. Stating the bleeding obvious, if you want to get kdelibs (or its successor) open to feature additions, help getting F5 ready, don't make it take longer. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/12/2011 12:55 PM, Christoph Feck wrote: Since it was me who raised this issue on IRC, I should clarify: I have no problem with the ksecrets stuff in *kdelibs*, but I do not like that it has been added to *kdeui*. The only reason given was that kwallet API is also part of kdeui, but why should we make this mistake again? Ok, I'll then move it somewhere else. I'm very tempted by the kdecore module, the place where it's main dependency, KCompositeJob, lives. But I think the best place would be the *experimental* module. Ok for that? -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
Since it was me who raised this issue on IRC, I should clarify: I have no problem with the ksecrets stuff in *kdelibs*, but I do not like that it has been added to *kdeui*. The only reason given was that kwallet API is also part of kdeui, but why should we make this mistake again? Christoph Feck (kdepepo)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
Valentin Rusu wrote: > However, I should remove the ksecretsserviced from kde-runtime and let > it go the the ksecrets repository, under kdeutils. And I'll do it later > today. Uhm, kde-runtime isn't frozen like kdelibs… Kevin Kofler
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On 11/12/2011 11:55 AM, Alexander Neundorf wrote: 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. So that was the intent of my previous email, now that the red flag got raised for inclusion in kdelibs master, Maybe the red flag for kdelibs can indeed be discussed again ? I mean, AFAIK, there will be a kdelibs 4.8 release, as stated by Dirk several times here and on other lists. If there is code right now which is working with the current kdelibs, reviewed and OKed (as ksecretsservice is), what exactly is the argument for not letting it in, and release it together with the kdelibs 4.8 ? It doesn't add extra work for the kdelibs 4.x branch, and it doesn't create extra work for integrating it with the frameworks branch. That's correct, thanks Alex. However, I should remove the ksecretsserviced from kde-runtime and let it go the the ksecrets repository, under kdeutils. And I'll do it later today. -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Saturday 12 November 2011, Kevin Ottens wrote: > On Saturday 12 November 2011 11:14:35 Valentin Rusu wrote: > > On 11/12/2011 10:11 AM, Kevin Ottens wrote: > > > 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. > > Yeah, I know that. > > > 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. > > So that was the intent of my previous email, now that the red flag got > raised for inclusion in kdelibs master, Maybe the red flag for kdelibs can indeed be discussed again ? I mean, AFAIK, there will be a kdelibs 4.8 release, as stated by Dirk several times here and on other lists. If there is code right now which is working with the current kdelibs, reviewed and OKed (as ksecretsservice is), what exactly is the argument for not letting it in, and release it together with the kdelibs 4.8 ? It doesn't add extra work for the kdelibs 4.x branch, and it doesn't create extra work for integrating it with the frameworks branch. Alex
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
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)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Saturday 12 November 2011 11:14:35 Valentin Rusu wrote: > On 11/12/2011 10:11 AM, Kevin Ottens wrote: > > 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. Yeah, I know that. > 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. 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? At least contrary to inclusion in kdeutils it would avoid the circular dependency issue. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
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)
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Saturday 12 November 2011 08:12:27 Kevin Kofler wrote: > Circular dependencies are an absolute PITA for packaging. Yes, obviously we're going to try to avoid that. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
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. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud patron of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part.
Re: Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
On Saturday 12 November 2011 08:12:27 Kevin Kofler wrote: > We definitely do want your ksecretsservice work ASAP and I don't see why it > can't be in kdelibs where it belongs. *sigh* could we please stop adding this whining about the frozen kdelibs in each thread on kde-core-devel. Yes we got that you want to have kdelibs open. Yes other people disagree on it and did a decision. It does not help your case by bringing up the discussion again and again. And it is completely unrelated to this thread here. If the module generates a circular dependency, then name it and propose an alternative which is a separate repo which does not bring in a circular dependency. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: [proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
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? > > 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 :-) I'll discuss this on the next > frameworks irc meeting or maybe a solution for this kind of situation > already exists? All this stuff is going to make things much more work for us packagers (just like the separate kactivities), for no good reason other than some arbitrary "we froze kdelibs" decision! Circular dependencies are an absolute PITA for packaging. We definitely do want your ksecretsservice work ASAP and I don't see why it can't be in kdelibs where it belongs. Kevin Kofler
[proposal] Move all of the ksecretsservice components into kdeutils/ksecrets
Hello, 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? 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 :-) I'll discuss this on the next frameworks irc meeting or maybe a solution for this kind of situation already exists? Cheers, -- Valentin Rusu (IRC valir, KDE vrusu) KSecretsService (former KSecretService, KWallet replacement)
