Archers,
In the current tdelibs pkgbuild, I have run into a few questions (previously posted). The current questions is why are we installing to provide 'kdelibs3'? Eg:
provides=('kdelibs3')
I have updated it to also register providing 'tdelibs' so that it can be transitioned:
provides=('kdelibs3' 'tdelibs')
Other changes: pkgname=trinity-tdelibs and cmake ${srcdir}/tdelibs for the build.
Does this just need to be reworked here, or are all of the build scripts going to have to be revised to incorporate the name changes? The name change is the simple part, but do we know if any of the patches or supporting files also have the 'kde...' stuff hardcoded? I'm fixing them as I come across them. If there is any reason not to, please let me know.
On 22 February 2012 15:37, David C. Rankin drankinatty@suddenlinkmail.com wrote:
Archers,
In the current tdelibs pkgbuild, I have run into a few questions (previously posted). The current questions is why are we installing to provide 'kdelibs3'? Eg:
provides=('kdelibs3')
This is bad. we do NOT provide kdelibs3 because they are NOT compatible. if anything we should conflict.
I have updated it to also register providing 'tdelibs' so that it can be transitioned:
provides=('kdelibs3' 'tdelibs')
Other changes: pkgname=trinity-tdelibs and cmake ${srcdir}/tdelibs for the build.
Does this just need to be reworked here, or are all of the build scripts going to have to be revised to incorporate the name changes? The name change is the simple part, but do we know if any of the patches or supporting files also have the 'kde...' stuff hardcoded? I'm fixing them as I come across them. If there is any reason not to, please let me know.
we should get rid of the kde stuff as we go. Leave 3.5.13 with kde references, git should be kde.
as we go is the best way :)
Calvin
On Wed, Feb 22, 2012 at 10:00 PM, Calvin Morrison mutantturkey@gmail.com wrote:
On 22 February 2012 15:37, David C. Rankin drankinatty@suddenlinkmail.com wrote:
Archers,
In the current tdelibs pkgbuild, I have run into a few questions (previously posted). The current questions is why are we installing to provide 'kdelibs3'? Eg:
provides=('kdelibs3')
This is bad. we do NOT provide kdelibs3 because they are NOT compatible. if anything we should conflict.
I have updated it to also register providing 'tdelibs' so that it can be transitioned:
provides=('kdelibs3' 'tdelibs')
Other changes: pkgname=trinity-tdelibs and cmake ${srcdir}/tdelibs for the build.
Does this just need to be reworked here, or are all of the build scripts going to have to be revised to incorporate the name changes? The name change is the simple part, but do we know if any of the patches or supporting files also have the 'kde...' stuff hardcoded? I'm fixing them as I come across them. If there is any reason not to, please let me know.
we should get rid of the kde stuff as we go. Leave 3.5.13 with kde references, git should be kde.
as we go is the best way :)
Calvin
This may be something left form my tests of compatibility. Try installing something that depends on kdelibs3 (see required by here: http://www.archlinux.org/packages/extra/i686/kdelibs3/) against our kdelibs and see if it works. Symlink may be required.
-
Calvin Morrison -
David C. Rankin -
Pawel Soltys