Upcoming in zypp.. Download all, then install!

YaST and zypper will finally have the ability to download all packages first and then install (commit post)! No more broken packages because of an aborted download due to connection issues!

 'Download in Advance' in action!

Notice the slight glitch in the 'Actions performed' List where 'Downloading XXX' line gets repeated

This was a much needed and essential feature which has finally been implemented. Though zypper will be getting configurable command line options for this soon, YaST can be setup by editing /etc/zypp/zypp.conf.

Here's the relevant part to be edited with 4 options available. 

##
## Commit download policy to use as default.
##
##  DownloadOnly,       Just download all packages to the local cache.
##                      Do not install. Implies a dry-run.
##
##  DownloadInAdvance,  First download all packages to the local cache.
##                      Then start to install.
##
##  DownloadInHeaps,    Similar to DownloadInAdvance, but try to split
##                      the transaction into heaps, where at the end of
##                      each heap a consistent system state is reached.
##
##  DownloadAsNeeded    Alternating download and install. Packages are
##                      cached just to avid CD/DVD hopping. This is the
##                      traditional behaviour.
##
##               If a value is not set, empty or unknown, we pick
##                      some save default.
##
commit.downloadMode = DownloadInAdvance

Now 'download in advance' policy should really be made default for 11.2. Right now it is 'download as needed'.

YaST also has configurable behavior for closing after installation. This is configurable via sysconfig editor. Three options: Close (closes after installation/removal finishes), Summary (which gives a nice summary of things that were done) and Restart (which sends you back to the default startup screen with search tab active).

Again 'Close' is still the default which is the worst possible option to keep as default. This should be changed to 'Summary' which should be more convenient for new users and which they can change later if they want, once they become more familiar with openSUSE.

A small rant about the Summary Screen: There always seems to be a difficulty with finding the correct names for buttons in YaST modules. Button names should be very clear regarding what the buttons are going to do. In the summary screen, there are two buttons "Back" and "Finish". Now an average user who is mostly familiar with the "Back" and "Forward" buttons used in a browser is most likely to think that the back button will send him to the previous page, which was the "Perform Installation" page with the flashing download/install progress bars. Hence, the user will click "Finish" which sounds more appropriate, with the effect that the window very rudely disappears. The current button names are more appropriate from the point of view of the installation workflow but are not good from the user's point of view. Some suggestions would be to rename "Back" as "OK" and the "Finish" button as "Quit". Also it would be better if the OK button was moved to the extreme right corner since users instinctively click corner buttons. The OK button also needs to be made default instead of Quit. Users like to click shiny highlighted buttons. Abort buttons should also be changed to Cancel and where ever  they are not required, they should be removed or made invisible instead of just disabling them.

Thanks to the devs again for the new features. Their efforts are commendable. One more step in catching upto the debian based distributions, though openSUSE has superior package management features of its own too. Now come the next essential features: Resuming downloads, downloading multiple packages in parallel and orphaned package removal!

Vpnc and Kde3 KNetworkManager in openSUSE 11.1

I was trying to connect to a VPN network today but network manager failed to connect. A dig through Network Manager's logs revealed an error message 'property 'Disable NAT Traversal' invalid or not supported'.

I googled and found a similar bug report in Ubuntu. It seems that at some point, the option of 'Disable NAT Traversal' got removed from vpnc but knetworkmanager never got updated. As a consequence, the connection fails.

The workaround described is simple and works for me. Just edit .kde/share/config/knetworkmanagerrc manually. Remove the lines:

<string>Disable NAT Traversal</string>\n <string>none</string>\n </entry>\n <entry>\n <string>Enable Single DES</string>\n <string>no</string>\n </entry>\n <entry>\n

Restart networkmanager (sudo /sbin/rcnetwork restart) and knetworkmanager, and try to connect again. This time, the connection should be successful.

I recall a similar bug report filed in bugzilla for opensuse but I am not able to find it now. The bug, if I remember correctly, has being fixed in svn but the fix still hasn't been backported or provided in an update. Till then, this workaround should help you to connect to your vpn network.

Package Search Module in YaST2

I came to know from this blog that there is a YaST module for searching software in openSUSE package repositories and Packman! Very cool indeed!

But it seems that the devs decided to keep this module invisible in YaST2 even though its there in openSUSE 11.1. Right now, the module can be launched from the command line as follows:

/sbin/yast2 webpin_package_search

But since I find this module to be incredibly useful, I added it to YaST. Here's how to do it. Just open your favorite editor (gedit/kwrite/kate) and paste the following lines in it.

[Desktop Entry]
X-SuSE-translate=true
X-SuSE-DocTeamID=ycc_webpin_package_search
Type=Application
Categories=Settings;System;Qt;X-SuSE-YaST;X-SuSE-YaST-Software;

X-KDE-ModuleType=Library
X-KDE-RootOnly=true
X-KDE-HasReadOnlyMode=true
X-KDE-Library=yast2
X-SuSE-YaST-Call=webpin_package_search

X-SuSE-YaST-Group=Software
X-SuSE-YaST-Argument=
X-SuSE-YaST-RootOnly=true
X-SuSE-YaST-AutoInst=
X-SuSE-YaST-Geometry=
X-SuSE-YaST-SortKey=
X-SuSE-YaST-AutoInstResource=

Icon=yast-sw_source
Exec=/sbin/yast2 webpin_package_search

Name=Software Search
GenericName=Search for software in openSUSE package repositories
X-KDE-SubstituteUID=true
StartupNotify=true

Save the file as webpin_package_search.desktop and move it to /usr/share/applications/YaST2 folder. Start YaST2 and you should now see a module called "Software Search" in YaST2.

Launch it to test if the module starts correctly. You now have the package search module easily accessible from YaST.

The devs also mention in the article comments that they are working on an application uninstaller which should do something equivalent to 'apt-get autoremove' in Debian and Ubuntu. Hopefully we should be able to see this in the next release, openSUSE 11.2. Even better would be if the devs can also implement an add/remove software module like the one available in Ubuntu. But I imagine the application uninstaller itself involves a lot of work, so even if they can get that into the next release, it would be really great!

Hope you enjoy using the package search module in YaST! Cheers!

Kdm3 in openSUSE 11.1

The KDE3 desktop installation for openSUSE 11.1 installs, by default, kdm4 or the kde display manager from the kde4 desktop.

Anyone who uses kde3 and finds the switch user options for 'start a new session' and 'Lock current and start new session' particularly useful, installing kdm3 will give you these options back.

For getting kdm3 back, install kdebase3-kdm.

sudo zypper in kdebase3-kdm

Then goto YaST2->System->/etc/sysconfig Editor.

In the tree listing on the left, go into Desktop->Display manager->DISPLAYMANAGER and change its setting from 'kdm4' to 'kdm' (Note: Don't use kdm3).

Save the changes (Click OK Button) and reboot. Kdm3 will now be used instead of Kdm4.

And on a side note, just noticed a lot of new visitors coming from tuxmachines.org. Welcome to my blog everyone!

Kima in openSUSE 11.1

Just realized that openSUSE 11.1 does not have kima packaged in the KDE community repository. Going through the build service repository, it seems that the build fails on suse 11.1 because of a few additional rpm checks which the build service has added.

A little bit of digging into the new checks and a small patch to the spec file and voila! Kima builds successfully for 11.1!

Get your kima from my home project repository here.

YaST Software Management module in openSUSE 11.1

For anyone who does not like automatically closing behavior of YaST Software Management module (or sw_single) in openSUSE 11.1, I have made a modified package (yast2-packager) which does not close automatically. Get it from my build service home project repository here.

I do not like the self closing behavior myself. No other package manager in any distribution does this. Even add/remove programs in Windows does not do this either. In 10.3, YaST used to ask if we want to install more packages or not, using a popup window. But as people find this popup irritating, the developers removed it. But I don't think whoever who wanted this also wanted the module to automatically close either. In terms of the user, I think the user will find both these things irritating: 1) Popups and 2) Windows which abruptly close without warning. A proper design would be where the number of clicks a user has to perform is least without experiencing the two behaviors described above. Now consider three use cases: 1) Popup removed and window closes automatically 2) Popup removed but the module does not quit. 3) Popup present.

For the first case, if a user does not want to do any futher software changes -> 0 clicks, or if YaST is open too, 1 click to close YaST. Let's give an average of 0.5 clicks.
If user want to make software changes -> if YaST is open, click software module (1 click); or go to openSUSE kickoff menu and click 'Install Software' (1 click); or go to openSUSE menu and click YaST, then click Software Management (2 clicks); All these can increase by one click if the user has the traditional KDE menu or the 'open on hover' feature does not work correctly for the buttons in the kickoff menu. Lets give this case an average of 1.25 clicks. (Note that making the user go through the menu again is not good design).

For the second use case, if a user does not want to do any further software changes-> 1 click to close the module, 2 clicks to close both the module and YaST if open. Let's give this one an average of 1.5 clicks.
If user wants to make software changes-> 0 clicks (module is already open).

For the third use case, if a user wants to make any software changes, click yes when popup is displayed (1 click).
If user does not want to make any changes, click no when popup is displayed (1 click).

Now, lets assign a fixed number of clicks (say 1 click each) to both popup and a self-closing window. So the first case will now have 1 click contribution from the abruptly closing window, the second case will have no contribution and the third case will have 1 click contribution from the popup (Here we are not counting the window closing as the user should be expecting the window to close when he says no).

On tabulating and averaging the clicks for the three cases, you can see that the second case has the lowest number of clicks.

	Case 1	Case 2	Case 3
No software changes	0.5	1.5	1
Software changes	1.25	0	1
Popups/closing window	1	0	1
Average	0.92	0.5	1

Some more observations: If for the first case, we reduce the clicks for 'more software changes' condition to 1, the average no of clicks will be 0.83 which is still larger than 0.5 for the second case. Further, if we reduce the number of clicks for software changes for the first case and then assume that the user gets accustomed to the window closing on its own, then making the contribution from it zero, the average number of clicks then matches the second case.

Some people may argue that they need something to tell them that software installation was successful or not at the end of the installation process. But then, if something does go wrong, the module does pop up more notifications/warnings than needed already!

In any case, I feel that its best to trust the developers to make the appropriate decision. Since openSUSE is open source free software, we can always make our own customized packages. Feel free to use the package in my repository but remember that its at your own risk!