Usually, whenever a new KDE release is published, Gentoo users can update already the same day, as suddenly a complete and polished set of ebuilds appears in the portage tree. (Stay tuned on upcoming wednesday for KDE 4.8.0, it's shaping up very nicely!) How is this possible? Well... let me explain.
If you're a stable version user, you may have never heard of so-called live ebuilds. This is a special variant, usually denoted by a version number ending in 9999, that does not rely on a source tarball. Instead, it contains a URL of a revsion control system (say on anongit.kde.org). When you emerge such a version of a package, the sources of the specified branch are checked out or updated to the newest upstream state, and that is used for building the installation package. Obviously this is not for everyone; depending how well upstream structures commits, things may not build for a while, contain fresh bugs, ... Also, reporting bugs from live versions on Gentoo bugzilla is discouraged as most of the times we can't do anything about it (do it only if you are sure it's a problem with the ebuilds, not with the source). If you're running live, you should be willing to hack yourself and work with upstream.
However, many of the Gentoo KDE team members run these live ebuilds, partly the current bugfix branch (i.e. KDE/4.8), partly even git master. They continuously keep the live ebuilds in the Gentoo KDE overlay updated to the newest state of the source. When a release is made, the corresponding live ebuilds of this branch are copied to the version ebuilds. For example, the KDE/4.8 branch live ebuilds have the version number 4.8.49.9999 (i.e.
kde-base/kdelibs-4.8.49.9999), so when the pre-release tarballs for KDE 4.8.0 were released to the packagers a few days ago, we only had to copy all 4.8.49.9999 ebuilds to 4.8.0 and immediately had a working set for testing. Most problems at that point are only caused by changes in tarball packaging. As distribution packagers get the pre-release tarballs (that still may change due to last-minute bugfixes) a week before the official release date, these can easily be fixed in time.
This also means that KDE maintenance in Gentoo is really a team effort. Whoever moves a released version to the main portage tree and/or commits bugfixes there builds on all the work that the team has done in the overlay in the meantime. Cheers!
That's one of the reasons, why I like Gentoo. I don't use the KDE live-ebuilds, but I use it for some applications like Bespin, KDE-Telepathy, Bangarang and others. The update of the live-ebuilds is very easy with the @live-rebuild Set.
ReplyDeleteAnd thanks for your great work on KDE on Gentoo.
I remember not so long ago that the bastion of objective reporting, Distro Watch, bashed us for not releasing a new version of KDE in a timely manner. For awhile now, the excellent people on the Gentoo KDE team release KDE versions to Gentoo users the day they come out. You will never see that in a Distro Watch article. Kudos to your team and thanks from a person that uses KDE every day.
ReplyDeleteYes, I'm replying to myself. Andreas pointed out the coverage of this blog on Distro Watch. If complaining is all I need to do to make things happen, I would like to point out that I have *never* won the lottery.
DeleteLooks like Distrowatch Weekly Issue 440 has a small blurb and link to this post. That is nice to see. I hadn't heard of the live-ebuilds in Gentoo before this. Thanks for the great post!
ReplyDelete