[arch-dev-public] On the road to KDE 4.1
Hey guys, I have made some packages of the first beta release of KDE 4.1. I had to update some dependencies and put them into [testing]. I also cleaned up the QT package. Due to a file conflict with kdelibs-4 I disabled phonon. The PKGBUILDs are built from scratch and I tried to keep it as simple as possible. This is more a test on how to package this stuff rather then testing the next kde itself. My suggestion would be: Let's create a kde-repo on top of our testing repo and see how we can package it and manage the transition from kde3. I have setup such a repo as an example: [kde-testing] http://users.archlinux.de/~pierre/kde-testing/x86_64/ There are the most important parts of KDE and in addition to this an example of how we could handle old packages which depend on KDE3: kaffeine. I would like to see some comments about this and some help would be nice, too. :-) Before putting this into you pacman.conf, please read this: This repo is just for testing packaging. It's incomplete and will break things. You should uninstall all kde3-stuff before: pacman -Rcsn kde Last but not least: especially to all "adventurous users" out there: please don't use this repo if you just want to have a look at the next kde; use one of the live-cds instead. Pierre -- http://www.archlinux.de
On Thu, May 29, 2008 at 3:43 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
My suggestion would be: Let's create a kde-repo on top of our testing repo and see how we can package it and manage the transition from kde3. I have setup such a repo as an example:
And the db-scripts are made to do just this! archrelease kde-testing-x86_64 # either manually scp the file, or use 'extrapkg' and them mv it on gerolde to, say, "~/staging/kde-testing/add". /arch/db-update kde-testing x86_64 It should error though, as I made a minor protection thing to ensure that someone goes on gerolde and creates the kde-testing dirs first.
On Thu, May 29, 2008 at 3:57 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 29, 2008 at 3:43 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
My suggestion would be: Let's create a kde-repo on top of our testing repo and see how we can package it and manage the transition from kde3. I have setup such a repo as an example:
And the db-scripts are made to do just this!
archrelease kde-testing-x86_64 # either manually scp the file, or use 'extrapkg' and them mv it on gerolde to, say, "~/staging/kde-testing/add". I smell moving this whole script to repopkg and then teh following: corepkg, extrapkg, communitypkg- still symlinks as now, except to repopkg repopkg- does not have a repo by default, so much be called as 'repopkg <reponame>' or something
/arch/db-update kde-testing x86_64
It should error though, as I made a minor protection thing to ensure that someone goes on gerolde and creates the kde-testing dirs first.
On Thu, May 29, 2008 at 4:03 PM, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, May 29, 2008 at 3:57 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Thu, May 29, 2008 at 3:43 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
My suggestion would be: Let's create a kde-repo on top of our testing repo and see how we can package it and manage the transition from kde3. I have setup such a repo as an example:
And the db-scripts are made to do just this!
archrelease kde-testing-x86_64 # either manually scp the file, or use 'extrapkg' and them mv it on gerolde to, say, "~/staging/kde-testing/add".
I smell moving this whole script to repopkg and then teh following: corepkg, extrapkg, communitypkg- still symlinks as now, except to repopkg repopkg- does not have a repo by default, so much be called as 'repopkg <reponame>' or something
That's a pretty good idea. Anyone want to patch devtools to do this?
On Thursday 29 May 2008 22:57:06 Aaron Griffin wrote:
And the db-scripts are made to do just this!
But this depends on the svn tree, right? ATM I don't wont to mess up with the repo. Think about a new KDE3 release before KDE4 is ready to use. What about using a git repo for this and put the repo into /ftp/other/kde- testing? -- archlinux.de
Pierre Schmitz schrieb:
On Thursday 29 May 2008 22:57:06 Aaron Griffin wrote:
And the db-scripts are made to do just this!
But this depends on the svn tree, right? ATM I don't wont to mess up with the repo. Think about a new KDE3 release before KDE4 is ready to use.
What about using a git repo for this and put the repo into /ftp/other/kde- testing?
Instead of polluting trunk, you could commit all work directly to repos/kde-testing-i686 and later merge to -x86_64. Then merge to trunk when all is ready.
On Thursday 29 May 2008 22:43:22 Pierre Schmitz wrote:
Let's create a kde-repo on top of our testing repo and see how we can package it and manage the transition from kde3.
OK, this was quite some work. I have moved the repo to other/kde-testing. This way it should be found on some mirrors soon. It's meant to be used in the follwoing order in pacman.conf: kde-testing testing core extra community Be warned: this will replace the existing KDE-3 packages by their equivalents of KDE-4.1. By installing kdelibs3 packages that depend on the old KDE "should" still work. (After KDE-4.1 is released to extra we "just" have to update the dependencies of the remaining KDE-3 packages; a rebuilt "should" not be needed) In order to not mess up things I have setup a separate git-repo containing all used PKGBUILDs: web: http://git.archlinux.de/cgit.cgi?url=kde-testing/ git: http://git.archlinux.de/~pierre/kde-testing.git Feel free to report any suggestions etc.. (by this I mean packaging bugs of course) If there is any dev who wants to help building this stuff for i686, please let me know. Happy bug-hunting, Pierre -- archlinux.de
On Sat, May 31, 2008 at 2:16 PM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Thursday 29 May 2008 22:43:22 Pierre Schmitz wrote:
Let's create a kde-repo on top of our testing repo and see how we can package it and manage the transition from kde3.
OK, this was quite some work. I have moved the repo to other/kde-testing. This way it should be found on some mirrors soon.
It could have been easier if you used the dbscripts to do this. Like Thomas suggested, you could do all the work in repos/kde-testing-i686/, commit everything, scp to ~staging/kde-testing/add/ (see Dan's repopkg patch for a helper script) and then run /arch/db-update kde-testing i686 This is actually the exact reason we did things the way we did here, with the repos/ dir and why I made the dbscripts work the way they do now.
Am Sonntag 01 Juni 2008 00:38:42 schrieb Aaron Griffin:
It could have been easier if you used the dbscripts to do this. Like Thomas suggested, you could do all the work in repos/kde-testing-i686/, commit everything, scp to ~staging/kde-testing/add/ (see Dan's repopkg patch for a helper script) and then run /arch/db-update kde-testing i686
This is actually the exact reason we did things the way we did here, with the repos/ dir and why I made the dbscripts work the way they do now.
Uploading the files and just using repo-add isn't that hard, too. The whole thing will be in flux for some time and I decided not to use our svn-repo. This makes it easier to keep things together and don't get lost. Using our current layout it's not so easy to just checkout those packages within a certain repo :-). Anyway: KDE 4.1 is still a kind of playground and I am not sure if they'll get it usable till Juli. ATM konqueror does not really work and plasma is pain. :-) -- archlinux.de
On Sat, 31 May 2008, Pierre Schmitz wrote:
On Thursday 29 May 2008 22:43:22 Pierre Schmitz wrote:
Let's create a kde-repo on top of our testing repo and see how we can package it and manage the transition from kde3.
OK, this was quite some work. I have moved the repo to other/kde-testing. This way it should be found on some mirrors soon.
It's meant to be used in the follwoing order in pacman.conf: kde-testing testing core extra community
Be warned: this will replace the existing KDE-3 packages by their equivalents of KDE-4.1. By installing kdelibs3 packages that depend on the old KDE "should" still work. (After KDE-4.1 is released to extra we "just" have to update the dependencies of the remaining KDE-3 packages; a rebuilt "should" not be needed)
In order to not mess up things I have setup a separate git-repo containing all used PKGBUILDs: web: http://git.archlinux.de/cgit.cgi?url=kde-testing/ git: http://git.archlinux.de/~pierre/kde-testing.git Feel free to report any suggestions etc.. (by this I mean packaging bugs of course)
If there is any dev who wants to help building this stuff for i686, please let me know.
Happy bug-hunting,
Pierre
I went to try out the i686 packages but there are file conflicts: error: could not prepare transaction error: failed to commit transaction (conflicting files) kdelibs: /etc/xdg/menus/applications.menu exists in filesystem kdegames: /etc/ggz.modules exists in filesystem Errors occurred, no packages were upgraded. $ pacman -Qo /etc/xdg/menus/applications.menu /etc/xdg/menus/applications.menu is owned by gnome-menus 2.22.1-1 $ pacman -Qo /etc/ggz.modules /etc/ggz.modules is owned by gnome-games 2.22.1.1-1 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Am Dienstag 03 Juni 2008 06:25:20 schrieb Eric Belanger:
I went to try out the i686 packages but there are file conflicts:
error: could not prepare transaction error: failed to commit transaction (conflicting files) kdelibs: /etc/xdg/menus/applications.menu exists in filesystem kdegames: /etc/ggz.modules exists in filesystem Errors occurred, no packages were upgraded.
$ pacman -Qo /etc/xdg/menus/applications.menu /etc/xdg/menus/applications.menu is owned by gnome-menus 2.22.1-1 $ pacman -Qo /etc/ggz.modules /etc/ggz.modules is owned by gnome-games 2.22.1.1-1
Thanks for the hint. I'll add replaces=(gnome) and conflicts=(gnome) to kde packages. Just kidding; I'll talk to Jan what could be done to avoid those conflicts; of course those files are different. -- archlinux.de
On Tue, 2008-06-03 at 08:40 +0200, Pierre Schmitz wrote:
Thanks for the hint. I'll add replaces=(gnome) and conflicts=(gnome) to kde packages.
Just kidding; I'll talk to Jan what could be done to avoid those conflicts; of course those files are different.
/etc/ggz.modules looks like a configuration file for libggz that should be generated from post_install/upgrade, not included in a package. I'll have a look at it soon. For kde3, we renamed /opt/kde/etc/xdg/applications.menu to kde-applications.menu, you might want to look at how we patched that. I think the same applies to kde4 in this case.
I just updated to 4.0.82 inlcuding some packaging improvements. (no i686 packages this time; I don't use them anyway)
participants (6)
-
Aaron Griffin
-
Dan McGee
-
Eric Belanger
-
Jan de Groot
-
Pierre Schmitz
-
Thomas Bächler