The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
Re: Reduction of features
by anonymous coward on Monday 07/Jan/2008, @12:05
|
This approach usually does not work. If your preferred app resides in a KDE mayor package, you can't cherry-pick it but have to pull the hole package, which maybe only builds against the unstable trunk kdelibs, but not against any stable version. That means that you have only two reasonable options:
(1) Live on the bleeding edge and use the trunk for all your KDE apps.
(2) Wait until the next release.
A more modular approach (i.e. git repositories for each app) would allow an app to proceed at its own pace and state its own preconditions.
|
[
Reply To This | View ]
|
Re: Reduction of features
by Morty on Monday 07/Jan/2008, @13:45
|
This approach does usually work, even if you have to get the whole major package you don't have to compile more than the application you want. Much the same way distributions split it in to individual packages for each application. The KDE packages are very modular.
As stated the only problem you can have are when the application require functionality not present in the current stable kdelibs, but the ability to only pick the application you want makes this less likely. In the past this has even been done officially by application maintainers, for instance Kopete has been released both as part of the kde and as separate releases.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|