New Package Blog, Controversy and KMail News for KDE 4.5

Synergy-Linux.com is gone

Well Synergy-Linux.com is down and will be for a while. At the time renewal came up, though not costly I couldn’t part with the moneys for various reasons. However Synergy-Linux.com was really just a portal for packaging work that was being done for KDE 4, Synergy Linux, and Unity Linux. Synergy-Linux.net is ran by Richard and is really the work horse for forums and community interaction. So one could argue not much was lost, well really nothing was lost but a few forum entries because a new blog can be found at http://synergy-linux.no-ip.org this is a webserver I have that hosts rpms and a blog off my home ISP. Here’s my plug for Qwest, they may not be the fastest ISP, but they don’t block ports, so I have had it pretty easy not having to do port forwarding etc.. to get things going.

Controversy

So right now there’s controversy in Unity Linux, well at least in my mind. I kinda feel that we have been focusing on updating more then stabilizing our current repositories. Now I very much could be wrong and I realize if anyone has been following the Mailing List they can see how harsh I can be, but much like some of our devoted users I really just want a stable release out already and I feel that over a year to create one is enough. I do understand how far we have came though and how much work it has been, a majority of it I haven’t really helped with so I’m sure backlash for the above statement is warranted. However I feel most if not all of the pieces are in place. Here’s an over view of all the work that’s been done.

• The Tool Chain :The team started out with a PCLinuxOS base and quickly found that for the direction we wanted to go the toolchain was too old. Instead of updating the PCLinuxOS base it was easier just to rebase off of Mandriva’s tool chain. From that point packaging relations started to quickly drift away from PCLinuxOS.
• RPM5: It was decided that RPM4 was becoming outdated, there were certain features and future visions in RPM5 that were attractive. Despite some views of the RPM5 maintainer, communication between Unity Linux developers and the RPM5 team was established and it was decided almost unanimously that RPM5 would replace RPM4. At that point rebuilding rpms with RPM5 meant that no other RPM4 distribution (ie Mandriva, PCLinuxOS) could use our binary RPMS. Unity Linux though can still install RPM4 based rpms though. This is just a symptom of using RPM5 it’s backwards compatible but not forwards compatible. It should be noted though that everything needed to still build a RPM4 based binary rpm can be found in Unity Linux SVN.
• Smart: PCLinuxOS used Apt4rpm and the used Synaptic as a frontend. Development for both Apt4rpm and Apt4rpm support in Synaptic was done by Connectiva and once Connectiva was bought by Mandriva development slowed tremendously if not some feel halted. I’m not sure on the status now, however to ensure a future without the work of maintaining both apt4rpm and support for it in Synaptic a different package manager and gui had to be chosen. So Smart was chosen for its versatility and power, however not so much for it’s gui (graphical frontend). The good news is with 1.4 new frontends for GTK and QT4 will be available so it was a wise investment in hindsight.
• Buildtools: mklivecd revolutionized PCLinuxOS and really the early adoption of it is what I feel lead to the success of PCLinuxOS, but now live distributions are almost the defacto and there’s multiple methods some claim easier methods. So now at the imaging level linux distributions are easier to create by users, however packaging a more detailed task can still be elusive. To try and help solve some of that elusiveness some awesome people on the Unity Linux team created a set of build tools. One can download a package from SVN update it, know a little about updating a spec file, and build with the build tools automatically update the changelog and find, download and install the buildrequires all with two commands. More advanced users can even setup a build environment and build for multiple architectures with one command and a few flags. Using SVN allows a more open way to display source and using the build tools (once understood) simplifies the build process. SVN access coupled with the Build Server (a web interface to a build system) now allows even a point and click method to build packages

• MKLiveCD: This is most likely one of the most controversial projects the Unity Linux team has adopted. Within the PCLinuxOS community even by the highest raking members it’s been expressed that MKLiveCD was stolen. I’m not sure how any opensource project can be stolen, normally that’s called a fork and that’s how opensource works. In no way has Unity Linux stole anything development has been open and published online since the initial announcement that work had been done. Some of the biggest changes to that of the MKLiveCD that existed at that the time Unity Linux was formed is multiple architecture support (right now 32bit and 64bit is supported) and support for kernels greater than 2.6.31. That’s not to say that PCLinuxOS hasn’t done their own work on their version of MkLiveCD (now referred to as MyLiveCD) but at least with their last release 2010.1 no 64bit version of the distribution was offered. Granted they still may support it in MyLiveCD, just not have the 64bit packages to create a 64bit version. This is one thing that testifies to the Unity Linux Build System and can be seen on the Unity Linux Build Server. When you build a package it builds for both popular architectures (32 and 64bit). It’s also obvious that they fixed the issues with going to a kernel higher then 2.6.31 as their current kernel is 2.6.32.12 and pretty fast from what I’ve read.

So it’s obvious (at least to me) Unity Linux has everything in place technically to be a success, whether it’s chosen to continue to release a minimal release, or too keep to the original plan to just offer a base repository and set of tools to allow other to create their own customized distributions (branches) and use Unity Linux as their core. At this point the only thing in my mind that’s holding people back is the announcement of a stable base and freeze on the stable repositories to allow people something stable to build from. This is not so say development shouldn’t continue on a unstable repository.

At this point my plan would be a SVN and RPM repository freeze. Create a copy of the current SVN repo and call it Cooker, Baker, Unstable, Mulched  or what have you and have all current upgrades to there until the next stable release. Work on the current SVN to fix bugs and only allow upgrades to CRITICAL issues, as in A program won’t work at this point unless B is upgraded. Create a LiveCD from RPMS based off what’s in the current stable SVN and RPM repositiory. Test and do major QA, very few packages should be updated at this point even in Unstable Cooker. Packages at this point should be making sure all the packages they are responsible for are in working order and tested. Release any given number of test releases every week to few weeks to the community to test with a general direction of what to test and look out for. Allow input on a forum and major issues reported that can be fixed should have a issue on the issue tracker assigned to the next current release label. However no matter what the next release should come out in a set time unless it’s a critical issue affecting a majority of testers.

I think this or a similar process should be done and very soon and it should be outline on whatever form of external media that’s related to Unity Linux

KDEPIM and Kmail 2

It’s been decided that the KDEPIM team will not release a new version till KDE 4.5 RC1 all of the Beta versions will be using KDEPIM from the 4.4.x series. Just thought I would let everyone know so it’s written somewhere. 😉