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

List:       kde-release-team
Subject:    Re: Release Script (KF5)
From:       Rex Dieter <rdieter () math ! unl ! edu>
Date:       2012-07-12 18:01:47
Message-ID: 4FFF110B.90809 () math ! unl ! edu
[Download RAW message or body]

On 07/12/2012 12:43 PM, Martin Gräßlin wrote:

>> Now, I'd have a much lesser concern if modules that are part of the 'kde
>> development platform' at least are never skipped.

> Could you explain why?

So, right now I can do a very simple runtime dependency for kde apps:

KDE_DEV_VERSION=$(kde4-config --kde-version | cut -d' ' -f1)

Requires: kde-runtime >= $KDE_DEV_VERSION

to ensure that this application pulls in (at least) the version of kde 
"stuff" used to build it.  (and kde-runtime in turn has versioned 
dependencies on stuff lower than itself in the stack, like kdelibs, 
kdepimlibs, oxygen-icons, nepomuk-core).

An analogue for libraries where the above is simplified to just
Requires: kdelibs >= $KDE_DEV_VERSION

Which happens to work quite nicely now in practice.(1)

Now, this will get much more complicated to track if the 'kde 
development platform' is no longer released as a whole and versions 
don't match up.  This, at least from my own POV, is where requests from 
packagers are coming that module inter-dependencies (esp versioning!) be 
clearly documented somewhere.

A lot of this could go away of qt/kde actually used symbol versioning 
too, but I digress... :(

-- rex

(1) A lot of this could go away if qt/kde actually used symbol 
versioning too, but I digress... :(
_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
[prev in list] [next in list] [prev in thread] [next in thread]