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

[Jaroslaw Staniek]

On 13 July 2012 10:11, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Friday 13 July 2012 Jul, C. Boemann wrote:
>> On Friday 13 July 2012 08:45:13 Cyrille Berger Skott wrote:
>> > On Friday 13 Jul 2012, you wrote:
>> > > Flexibility is a +1, but one -1 (besides adding further complexity to
>> > > cmake files) is that these build profiles should only be used for
>> > > custom builds. We don't want stripped-down Word in the popular
>> > > distros, for example, not being able to handle the Biblio feature.
>> >
>> > You really don't have to worry about distributions, packagers will package
>> > with every optional dependency as possible, and as long as they are listed
>> > at the end of the configuration step, they will notice them and include
>> > them. This is why we often get the complain that Calligra installation is
>> > bloated. Personnaly, I think it is ok.
>> >
>> > However I thought we were in agreement that we wanted to make it possible
>> > to create very lightweight custom build of calligra with as few
>> > dependencies as possible.
>> >
>> > In any case, new hard dependencies need to be discussed and announced on
>> > the mailing list in advance.
>> uhm there was a review request for about a week
>
> Yeah, I saw that request. But that's not the same same as writing a mail to the mailing list announcing extra dependencies. I saw the request, but I was blindsided by it as well.

It was announced and put as RFC on 3rd July:

http://lists.kde.org/?l=calligra-devel&m=134135216226096&w=1

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.

 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). 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. 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. 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.

-- 
regards / pozdrawiam, Jaroslaw Staniek
 Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org
 Qt Certified Specialist | http://qt-project.org
 http://www.linkedin.com/in/jstaniek