[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: What to test for 4.13?
From:       Ian Wadham <iandw.au () gmail ! com>
Date:       2014-03-17 23:12:57
Message-ID: 1F0E3F7D-3BFB-4917-BA0D-3799DBFB5979 () gmail ! com
[Download RAW message or body]

Hello Kevin and Marko,

On 17/03/2014, at 6:59 AM, Kevin Krammer wrote:
> On Sunday, 2014-03-16, 20:45:49, mk-lists@email.de wrote:
>> On 16 Mar 2014, at 20:34 , Kevin Krammer <krammer@kde.org> wrote:
>>> A dependency in two versions of GTK?
>>> For a non-GUI program?
>> =

>> I even had a case with a port (don=92t remember which one though) where
>> actually LaTeX was required just because there was some documentation st=
uff
>> to be converted from tex to pdf=85 Imagine to have to build LaTeX just f=
or
>> generating a piece of documentation. LaTeX=92s tools then also pull in X=
11
>> due to ImageMagick and poplar! (It never ends.)
> =

> Yes, but those are build dependencies, right?
> The binary packages are not affected by this, are they?

Here are some statistics that might interest you.

Two days ago I did "sudo port upgrade outdated" on MacPorts,
which automatically updates all those packages (including
recursive dependencies) for which there is a more recent version.

    Requested (by me at some time in the past)       14 packages
    Installed two days ago                                           311 pa=
ckages

    Installed from binary                                               234=
 packages
    Built from source                                                      =
  77 packages
    Built from source (excluding KDE Games)           34 packages

    Run time                                                               =
      4.5 hours

My hardware is 2GHz Intel Core i7 (4 cores) with 4GB 13333 MHz DDR3 memory.

I am not surprised that MacPorts still has all the KDE Games as source code
packages.  After all, they are providing packages on four different Apple O=
S X's.

The surprises among the remaining 34 packages (for me) were: boost, ghostsc=
ript,
mysql5, poppler and inkscape.  Some time-consuming ones were boost (more
than 30 minutes) and mysql5.  Also virtuoso, soprano and nepomuk-core were
among the source-code set, as well as some Marko has mentioned.

In my view, there are two major underlying causes for the size and "reach" =
of these
dependency chains (e.g. ghostscript - what's that doing there?).

   1. kdelibs4 depends on Nepomuk et al. and that brings in a long chain of
       non-KDE packages that are used, directly or indirectly, by Nepomuk,
       ending (on MacPorts) with spurious dependencies on X11.

   2. There has been trouble with meinproc4 in the past on MacPorts and so,
        if you ask for +docs versions of packages you get a whole lot of TeX
        type dependencies, IIUC.

As I understand it, Nepomuk is in process of being replaced by Baloo.  I wo=
nder
if it would be possible to patch out the Nepomuk dependency and put it in a
different KDE library - whether at the KDE end or the MacPorts end I do not=
 know.
Apple OS X already has, as standard issue, a thing called Spotlight that in=
dexes
your files, email, etc., though not semantically, I think.

Re +docs, if you are going to play a KDE Game you need to know the rules, so
you need the Handbooks, but on MacPorts you also get the API (internal) doc=
o,
and you get all those dependencies.  I do not understand why, ATM.

I have posted about this on the MacPorts list, but it is an ongoing problem=
.  I have
been using meinproc4 daily on Apple OS X in the past weeks, as I composed
documentation for the 4.13 release of Palapeli and it has given me no probl=
ems
at all.  Maybe we need an effort to get to the bottom of this one, but wher=
e to start?

I just now tested that my "make" command is in fact using meinproc4, by usi=
ng
"sudo mv " to (temporarily) rename the meinproc4 executable file =85 ;-)

Cheers, Ian W.








>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscrib=
e <<
[prev in list] [next in list] [prev in thread] [next in thread]