FOSS.IN, a Free software conference in Bangalore, India has put out the call for proposals and we have a very short period of about a week more for proposals. A prelimenary proposal from Fedora India has been send to the organizers for a Fedora Project day. If you involved with any upstream projects, you can register as a speaker to present a individual talk as well. Get in touch with me if you have any questions. Let’s get the ball rolling.
KDE in Linux distributions
KDE in Linux distributions tend to be always a emotional topic to KDE fans for some reasons The recent openSUSE controversy is fresh in everyone’s minds but a long time before, there was a enormous revolt against UserLinux because it said that they will just ship with GNOME. UserLinux wanted to just streamline the distribution heavily and pick one default covering specific functionality. The choices were debated extensively and none of them came out to be as controverisal as the decision to pick a default desktop environment even though the decisions were explained in length. UserLinux is dead and burried. All that revolt served absolutely no real purpose at all.
Ubuntu was explained in a Linux conference by Jeff Waugh a while back when he was a Canonical employee and one of the very initial whiteboards on their brain storming process explained the goals and one of them that stood out to me was “To be a better Fedora than Fedora” and Ubuntu did learn a lot from the Fedora process on what to do and what not to do. The time based release process and not to screw up the initial launch for example. However perhaps they also did learn extensively from UserLinux. They positioned Ubuntu to do a lot of what UserLinux had originally planned to do. One item for each functionality, a wide support marketplace and so on. Because they understood the leaving out KDE from Ubuntu would be a contoversial move, they decided to go with completely separate branding for each of their variants – Kubuntu, Xubuntu etc. This move has its own advantages but it results in asymmetric branding. Ubuntu is both the project as well as the default distribution while others are alternatives. The problem doesn’t end there though. They vehemently deny it but Kubuntu really is just Ubuntu with KDE swapped for GNOME. In other words, Kubuntu is a KDE Spin of Ubuntu.
In a recent article about Kubuntu, it was criticized as going on a downward spiral. I don’t agree with many of the criticisms, especially the claims that additional sauce on top of vanilla KDE is really necessary including patches or different branding. People really need get rid of that notion that staying close to upstream is a bad idea. It dosn’t mean you need to go blindly with whatever upstream provides but if upstream does provide a good theme, it is ok to just stick to that. Fedora includes GNOME by default but has switched but custom Nodoka theme to just vanilla upstream Clearlooks theme and GNOME support in Fedora remains top notch as it has been in the past. Among the mainstream distributions, it makes Fedora still stand out nicely because everyone else is shipping a custom theme! The response from Jonathan Riddell, lead developer of Kubuntu on the wireless situation is extremely puzzling to me:
“Kubuntu is a KDE distribution, we use only KDE and are the only major distribution to do so. This means when KDE misses something we do too, we can only ship with what exists. Unforunately when Jaunty released there was no good KDE network manager. That hurts but there wasn’t any better KDE choice. “
With all due respect, I have heard similar arguments before and that’s pure unadultered nonsense.. If you install ubuntu-desktop metapackage in Kubuntu, your OS gets converted from Kubuntu operating system to Ubuntu operating system? No, not really. It is just the same operating system and distribution with a different desktop environment. Pretending that Kubuntu is a separate operating system or distribution really is painting yourself into a corner and being religious about it means that you ship a really broken native client as opposed to just including nm-applet which works better than the KDE plasmoid at the moment. Sure, it lacks nice integration with KDE Wallet etc but why pretend there is no alternative at all? Fedora KDE Spin has included nm-applet for sometime and has far less complaints about breakage. Sure, KDE in Fedora is no perfect desktop environment either but a community should be willing to make compromises and use the best of what it is available instead of knowing shipping a broken default. Shipping GNOME or GTK software in KDE oriented Live CD is just fine when it is the better choice. I am not contributing to KDE in Fedora but I am really happy Fedora KDE team is willing to make pragmatic choices such as this.
Thunderbird problem gets fixed
The last Thunderbird 3 (beta 4) update issue I talked about in a couple of posts has been fixed and users should get a new update that disables both indexing and smart folders by default. Many thanks to the maintainers for being responsive and resolving the issues quickly. Christopher Aillon, primary Thunderbird maintainer in Fedora explained the details here.
A related issue: One of the problems which is quite common with Fedora updates is the lack of detailed description of changes. That was the case for the earlier thunderbird update as well. If you cannot highlight the important changes, the minimum you should do in every single update is to link to the upstream changelog or release notes. If you as a maintainer of the software do not atleast try to explain the changes to your users, it is not really appropriate to push the change in the first place. One way to avoid issues is to avoid pushing every single upstream release an update.
Describing the changes in a bit more detail would really help testers focus on the important changes as well as help end users determine whether the update should be applied on their system. There is a set of general package update guidelines that maintainers can follow. I don’t really think I am a perfect maintainer either. I goof up often as well. It only becomes a serious issue when people involved refuse to accept that there is a problem worth resolving. Thankfully for the maintainers involved, that was not the case this time. Sanity returns.
In the name of “Evolution”
Tim Laurisden, it is not just about “look and feel different”. It is about my mail client being unusable for quite sometime after an update. Many buttons went missing from the toolbar. My folders were rearranged. This isn’t something that is expected to happen with an update.
It is not upstream responsibility that Fedora picked up a beta release and pushed an update that caused this frustration. Xorg zapping was disabled in a new release with proper release notes. Behavior changes like that in a new release is ok. An update causing this is unacceptable. That is my opinion and I am sticking to it.
Btw, Evolution is something that happens gradually over a longer period of time. Disruption is not Evolution.
Stop screwing around with updates
If you have been a Fedora 11 Thunderbird user, the last update was likely to cause you some confusion. Two primary things:
* Smart folders
* Global indexing
While these are useful features, pushing them as an update was a really bad idea. These features should have been disabled by default in an update. The first feature rearranged my folders. Suddenly my Inbox had moved from where I expected it to some place else completely. It can be disabled by the really tiny arrow marks on top. The second feature of course sucked up CPU trying to index gigabytes of my mail while I was waiting around trying to send a urgent email. Again, this feature too can be disabled in the UI.
Maintainers should really think about whether they want to push a beta release of any software into a stable release of Fedora. If the advantages are really prominent, take extra care before pushing any updates. Think about whether the update is really necessary. If so. one week time in Fedora updates-testing is just not enough to get enough feedback on this.
While I have started running Rawhide primarily and can cope with this problem, this is not an acceptable way to treat our end users. If you are a Fedora user, I appreciate you letting us know your feedback.
Preventing dependency breakage – Part II
My previous post has generated a bunch of discussions and I think it is worthwhile highlighting what I believe is the way to mitigate this and answer some of the concerns. I am using a FAQ form for this:
Who is responsible for the dependency problems?
The individual package maintainers are responsible for the packages they maintain and release engineering, QA team and others share the burden on finding a good solution to the overall problem. To be fair to package maintainers (I am one of them), maintaining three or four different branches (Fedora 13 – 10 at this point) for multiple architectures is not easy. A lot of maintainers do maintain more than one package and this means that we cannot expect the individual maintainers to do a perfect job. It is currently very easy to break the repository by a unintentional push as has happened over and over again including very recently.
What about a security update that breaks some dependencies. Isn’t fixing the security hole more important?
Not really. Yum’s current default behavior is to bail out if there are multiple updates and some of them have dependency issues. If you truely want users to benefit, fix the dependency issues before pushing the update. No exceptions.
Is anyone finding a solution?
Indeed. The AutoQA project from the Fedora QA team has been busy at work and one of the things would be to check for dependencies automatically. This should help us avoid pushing updates with dependency issues.
So just sit tight?
You can be patient or contribute to the AutoQA project but I think the short term way to mitigate this problem is by setting the skip-broken=1 option in /etc/yum.conf.
Interesting. What does that do?
It skips the packages that has dependency problems and updates the rest. You can either do yum update –skip-broken or set it permanently in /etc/yum.conf.
Sounds wonderful. Why are we not taking advantage of this already?
We are… to some extend. PackageKit already set this value in the yum backend it is using and users who use PackageKit (via one of its frontends) should not be seeing as many dependency breakages.
A lot of users however continue to use yum on the command line and these include non-power users on the desktop. Ideally, the graphical interfaces would solve all the desktop users needs and we don’t have to worry about command line users much but we are not there yet.
Why didn’t yum have this option set by default before? What are the downsides?
When skip-broken was first introduced it didn’t help skip many of the dependency problems. Over a period of time it has improved considerably. It is not perfect yet since there are a bunch of issues that you cannot easily detect beforehand. For example, file conflicts between packages across multiple repositories including third party ones. However setting it by default would help things considerably.
Another concern is that setting the skip-broken option by default would mask the dependency issues and users wouldn’t realize they are missing out potentially important updates. They wouldn’t report bugs and hence maintainers wouldn’t fix them soon. This was a valid point of view and one that I agreed with but yum in later revisions does list all the packages that are being skipped due to dependency issues if you use the skip-broken option.
What about system administrators who want to be informed of the dependency problems? How would they be aware of it?
If a sys admin is managing multiple systems, a test system can be used. There are tools to check the repository state and updates can be pushed directly using management tools like Spacewalk.
How will maintainers be aware?
In many cases, they get automated emails informing them of the problem already. However if you run across dependency issues in the Fedora repository, please take a moment to report them so that maintainers are aware.
You can do that via http://bugz.fedoraproject.org/ or add a comment to that update at http://admin.fedoraproject.org/updates
Why don’t you just document this option and be done with it?
That is already done but it doesn’t help much. Most users don’t read documentation. I have spend a lot of time on documentation, far more so than your average Fedora contributor and my experience is that users don’t read documentation much, if at all. The only reason I did contribute is because it is easier to document and point users to the link rather than repeat myself all the time.
If the software can be tweaked to provide a better out of the box experience, that is always going to be a far more superior solution than documenting workarounds.
Should yum set skip-broken by default now?
I believe so, yes. It is the decision of yum developers however and if they disagree that this should be the default, it would be good to understand why.
Meanwhile, I recommend users set this value and continue to report dependency issues. I will update this FAQ if there are more unanswered questions on this topic.
Fedora 12 and Yum Presto Plugin
Though yum-presto plugin that enables the end users to consume delta RPMs or binary diffs of updates has been in Fedora for a long time, Fedora 11 was the first Fedora release to provide it in a more integrated capacity. Bodhi, the Fedora updates system will push out delta RPM’s along with the full RPM’s and createrepo can generate delta RPMs for your custom repositories as well.
All you had to do to enable it was just yum install yum-presto and boom, you had much faster updates and less bandwidth usage. There is a trade off however in slightly higher CPU consumption while installing those updates since the full RPMs are actually generated on the disk before installing them however most users do enjoy the benefits.
In Fedora 12, I had expected yum-presto to be made available by default and that didn’t happen due to various people and process issues. However many users will still get it by default. Here is why:
I added it to the GNOME Desktop group after talking to the Desktop team and KDE SIG has added it to the KDE Live CD kickstart file instead (for users using the dvd or installing KDE post-installation, you have to install yum-presto plugin seprately). So the benefits are available to more people out of the box in Fedora 12.
Jonathan Dieter (maintainer of yum-presto plugin) did come up with a couple of problems that he suggested needs to be fixed before release. The second bug which causes more CPU usage has been fixed by setting LZMA compression level to 2 in redhat-rpm-config package. It appears that LZMA compression format has a problem which is exposed by deltarpm that results in the first bug. Apparently it requires changes in the build system or the software to be patched to workaround it. Otherwise uses will see a MD5 mismatch error when yum-presto downloads the drpm for some noarch (architecture independent packages such as documentation, fonts and scripts) and it will fall back to downloading the full RPM instead. Even with this problem, yum-presto is still very useful. Not sure whether we are making the changes to the build system or fixing the format before Fedora 12 release. If anyone is taking care of that, let me know.
Preventing dependency breakage
Fedora has a increasingly large number of software packages.
# yum repolist
Loaded plugins: presto, refresh-packagekit, remove-with-leaves
repo id repo name status
livna rpm.livna.org for 11.91 – i386 enabled: 3
rawhide Fedora – Rawhide – Developmental packa enabled: 15,078
rpmfusion-free-rawhide RPM Fusion for Fedora Rawhide – Free enabled: 469
rpmfusion-nonfree-rawhide RPM Fusion for Fedora Rawhide – Nonfre enabled: 122
repolist: 15,672
That’s a impressive number of packages and growing at a very fast rate. Good news for everyone. However dependency breakage is not that uncommon.
https://admin.fedoraproject.org/updates/F11/FEDORA-2009-10088?_csrf_token=0e53ac11a223380d5c82fcad8d18a816da59454c
http://mso-chronicles.blogspot.com/2009/09/broken-deps-libassso3.html
That’s not good news for anyone. It reduces trust in the Fedora Project and people blame the maintainers or even worse, they blame yum for it. It is not reasonable to expect maintainers to do a perfect job. We really need to ensure that absolutely no packages get pushed out without a basic dependency check. It does not matter whether it is a security update. It does not matter that it will take a few hours or even a day more. I don’t want to see another dependency breakage when using the official Fedora repositories. Never again.
Fedora and Software Patents
After getting a bit tired of the same discussions over and over again about MP3 codecs, patents etc, I have now written up a page that tries to answer the common questions that Fedora users have on this topic. I hope it is useful for our users but it is not legal advice. Take a look and let me know what you think.
Omega (Pug) Release
Want Fedora 11 but don’t like the hassle of setting up RPM Fusion and Livna? Go grab Omega, right now. It is a Fedora Remix with full multimedia capabilities in a single streamlined installable Live CD. Awesome features like Presto yum plugin out of the box with all the updates up until today rolled in. It even has a nice website and a Pug waiting just for you. Download it and have fun.
The post is brought to you by lekhonee v0.7
