-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30-12-2009 11:45, Kevin Krammer wrote: > On Wednesday, 2009-12-30, Jorge Manuel B. S. Vicetto wrote: >> On 29-12-2009 23:09, Mike Arthur wrote: >>> On 29 Dec 2009, at 23:43, Jorge Manuel B. S. Vicetto wrote: > >>>> As Maciej hinted, you're opening the door for another group of KDE devs >>>> later call for precedent to add hard deps on sqlite, postgres or >>>> whatever is their favourite DB. Requiring full blown relational >>>> databases for a DE is probably a good sign that someone is going in the >>>> wrong direction. Again, I can point you to comments by users in Gentoo >>>> bugs complaining about this - it's not just "my individual opinion". > > An interesting observation around this topic is that while it is usually > preferred to have shared implementations, some people seem to prefer that > relational data organisation is reimplemented for every use case separately. > > From a developer point of view this doesn't make sense since one would spend > resource on work somebody with most likely better understanding of the > problem > domain has already done. > > From operating system vendor's point of view it doesn't make any sense either > since it will require to distribute a lot of different implementations which > basically do similar things. > > From a system administrator's point of view it is even worse since hand > crafted code for special cases will be more likely to have bugs, even > security > related ones that implentations with a broad usage spectrum will not have or > have fixed more quickly. > > As I said it is quite interesting that this is common sense for almost all > parts of the software stack but not for software handling relations between > data.
I agree fully with your argument. We (Gentoo) do prefer to have dependencies on shared and reliable packages than to have packages with "home-grown hacks" or local forks. In that spirit, we actively unbundle bundled libraries already present in Gentoo (a common source of security issues with packages). >>> Another way of looking at it which you perhaps haven't considered is that >>> dependencies are a good things as they are shared, stable code that we >>> don't have to maintain. This means KDE can get better rather than >>> worrying about how to store information on disk. In KDEPIM, for instance, >>> moving to Akonadi and using a database has allowed a lot of code to be >>> removed. >> >> It seems you have misunderstood my comments. I have no objection for KDE >> to include dependencies on common, shared projects. My objection is >> about the hard dependencies, in particular to add such deps to kdelibs >> when they are only required for individual apps / modules. > > Good point. > I think this has been a misunderstanding. People here assumed it would be > more > convenient to have core modules depend on things and not have to track > individual apps usage of them, while packagers actually prefer tracking > individual dependencies to keep dependency chains for other programs short. As a packager, I would very much appreciate clear and complete deps for each app than having to scroll through all the CMakeLists.txt files and determine the correct deps for each app in a module[1]. That is why I was so vocal about adding a "wrong dep" to kdelibs, just to make build files "simpler". Especially since it meant adding a lot of "bloat" to all KDE installs. [1] - This is exactly what we talked about with Alex in FOSDEM'09 as I mentioned in the first e-mail. In our view, it would be simpler to get the dependencies correctly fixed, if the current modules were split and or each app was fixed to be built on its own - without relying on the build of the complete module. >>> Your concerns are known already, they were raised loudly when MySQL was >>> first proposed for Akonadi and for Amarok. However, unless you have an >>> actual technical solution to the problem that many of the KDE developers >>> have tried to solve then raising these issues again is just demotivating. >> >> I'm sorry if my comments are received as demotivating, that was not my >> goal. What lead me to post to these mls (after months of silence) is >> noticing that KDE wants to go further and add another relational >> database dep. >> Seeing how Maciej's email and patches were received, how some of you >> can't see why making such deps optional is important and as a KDE >> packager for Gentoo, I'm trying to get you to rethink about KDE deps and >> in this case to drop the soprano hard dep requirement. >> Two points I get the impression some of you may have forgotten is that >> not all users want the complete KDE DE and that some distributions do >> not force the complete KDE DE onto their users. > > As I wrote above, I think the misunderstanding comes from assuming that > downstream would prefer fixed dependencies while you actually prefer checking > each application's runtime dependencies individually. > Or maybe it differs between downstreams, etc. I can't talk about other distributions, but you're right about Gentoo. Thank you for making my arguments clear and for addressing them. > Cheers, > Kevin PS - To answer your question about "full blown relational server", we mean having a complete DBMS environment, thus including a server process, instead of having a simple embedded DB. In case you're wondering, it's not about having a statically linked DB in each KDE program that requires use of a DB. In fact, we do prefer shared libraries and that's why I cared enough to get libmysqld built as a shared lib. It's about having a DB server instance running on a desktop, with the impact on system performance (system wide and not specific to any KDE app) and exposing unaware users to security risks. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks7hXoACgkQcAWygvVEyAJ6EQCeJEEtkK0rn208hScMumtjKT6G 7IwAn3v9mAPO3I9qd89hjbZu1S3bM0tT =Qslw -----END PGP SIGNATURE----- _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
