[calligra] /: Move core parts of KexiDB lib to libcalligradb

[Boudewijn Rempt]

On Friday 13 July 2012 Jul, Jaroslaw Staniek wrote:

> It was announced and put as RFC on 3rd July:
> 
> http://lists.kde.org/?l=calligra-devel&m=134135216226096&w=1

Sorry, but that was completely unclear. Clear would have been "proposal for adding sqlite and icu as dependencies to all calligra applications". Yes, you cannot rely on people clicking on a link that just talks about minutes for an irc meeting for words. Something that says "Just published minutes from the meeting - KexiDB adoption in Words Biblio module:" is not request for comments. It's a report of a meeting that probably is irrelevant for everyone who's not working on words' biblio module, or even not working on words.

And yes, I am sorry, but I am way too busy to check every review request thoroughly and follow every link. If you want to do something that touches what I am working on, you have to be explicit in your communication or I will miss it.

> At that time involved developers exchanged our concerns, cleared up,
> and the still was in a form of idea. 4 days after it materialized as
> review request.

And now the "uninvolved" developers are a bit surprised, which should not surprise any of the "involved" developers.

>  As you see in my original reply I provided data on what most users
> already have on their systems: they have libsqlite almost for sure,
> and will have to keep ICU lib in the near future.
> 
> I would not exaggerate the dependency aspect before we formulate the
> demand of lightness (maybe with help of users and statistics). 

Already I have to defend that krita drags in so many dependencies. Dragging in a database for a paint application is indefensible. Whatever people might already have on their systems. We'll get the same problems amarok and akonadi have to endure, which, as with amarok and akonadi have seen means users stop using the software.

> Before
> that the demand looks for me a bit like the demands of dropping
> dependencies on KDElibs and stay 100% Qt-only (this is popular request
> from time to time in comments whenever we announce another Calligra
> version).
> 
> I hear that Bibliography is a tier-1 feature of ODF and ODF is core
> functionality.

If it is, it's only for ODT. So only for words. Not for any of the other Calligra applications.

> What's in ODF specs influence our architecture, we have
> rarely discussions on skipping some ODF parts. I see a need to be more
> active when it comes to features out of scope of ODF, such as
> higher-level integration (and data handling, topic which was skipped
> in the final ODF 1.1 for purpose).
> 
> Otherwise, please let's find convincing cases, not corner-cases, when
> given user group intentionally degrades functionality this way on a
> desktop system. Sure splitting everything to plugins is possible. The
> question is not 'how' but 'why' and 'what'. I am afraid the voices
> demanding fragmentation of the packages of are the loudest ones, but
> not represent real user base.

Why do you think that? Who do you think the real user base of calligra are?

> Personally I feel we're loosing some
> energy (which would be more utilized for Calligra Engine works?).
> Even if we look at the potential concerns, I think both reasons are at
> most equal:
> 1. size of dependencies
> 2. number of packages that form dependencies (even if just recommended/optional)
> 
> I understand the demand boud expressed is to decrease 1. and increase 2.
> 
> I have almost nothing against extending README.PACKAGERS to suggest
> moving  libcalligradb to extra recommended package that will be used
> only when needed. Almost nothing, with exception of the point 2.
> above. I am afraid the more _pedantry_ lies in README.PACKAGERS
> recommendations, more chances are that some distros will ignore that
> altogether and can understand them.




-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl