All entries for February 2008

February 26, 2008

Easier YMP Creation

Some people have requested a GUI for creating YMP (One Click Install) files (It seems some people have an aversion to XML) .This is something I had looked at in the past, but decided that it the resulting UI would be at least as complex as the generated XML.

I had another go at this today, and the resulting form really doesn’t seem to be much easier to use than writing the XML manually.

All you save is typing out the tags, which an XML editor would help you with anyway.

Perhaps a better approach for simple YMPs would be to convert user selections within the package management into a one click install file.

YaST software management (at least the Qt version) does provide a mechanism to export user selections to a file:

Which generates a file like

[Update]             MozillaSunbird                 |   21.0 M   | 0.7-6.3          | 0.7-6.3         
[Install]            MozillaSunbird-debuginfo       |    5.7 M   | 0.7-6.3          | ---             
[Install]            MozillaSunbird-translations    |   11.6 M   | 0.7-6.3          | ---             

It might be possible to convert this file into a YMP automatically, which would make generating simple YMPs easy. I might have a go at this sometime. However, it will not help creating complex YMPs with support for multiple distributions/versions, and translations.

Does anyone have any other suggestions for approaches to ease creation of YMP files for one click install links?

February 19, 2008

Third party updates

James since your blog doesn’t appear to support comments I’ll stoop to “discussion by blog”.

You state that third party repositories are not considered by the updater tools (YaST Online Update,Updater applet, zypper). This is not really true. In fact, by default the tools will only notify you of updates that are patches (higher priority than newer versions of packages). These patches could be in any repository, in practice they are only used in the official update repository. There is some more information about how patches are specified on the wiki .

Now, while only these “patches” are considered important enough to notify the user of, and apply automatically, other repositories are considered while performing the updates. This means that in the case of a new kernel patch being released which is incompatable with the currently installed nvidia driver, the kernel patch will not be installed until there are updated nvidia drivers available in the nvidia repository that will work with the new kernel. Once there is a new nvidia driver available the update will install and will pull in the updated nvidia driver from the other repository as a dependency automatically. The same should happen with madwifi, though they were quite slow in making new drivers available for the recent kernel updates, if it does not then it’s probably a packaging issue. There is more information about kernel module dependencies in this paper.

Furthermore, if you wish to be notified of new versions of packages in any repository, as well as patches, you can be. Simply tick the “Show upgrades” tickbox in the updater.

You can also do this with zypper

zypper up -t package

(That’s a literal “package” , not a package name)

This is not enabled by default as just because a user has a repository available in his or her package manager it does not mean that he or she necessarily wishes to install newer versions of packages just because they are there. For example packman repository has had problematic alsa upgrades in the not too distant past, which most people do not want. There is also the issue of “vendor bouncing” where a newer version of a package becomes available in one repository, and then in another, and so on. There are other ways to resolve that though, such as vendor sticky (Assuming the user wishes to stay with upgrades & updates from the same vendor, unless he or she specifically installs one from another vendor).

February 11, 2008

Command–Not–Found on openSUSE

Ubuntu ships with a programme called command-not-found which will suggest a package to install when the user types a command at the terminal which can’t be found. It seems this makes use of a hook called command_not_found_handler() which is not available in SUSE.

Pavol Rusnak is working on porting this programme to openSUSE, so it might be available for 11.0. But is it possible to get this behaviour on a vanilla openSUSE 10.3 without installing any other packages?

It does seem possible to do something hacky to get such behaviour:

if [ $? -eq 127 ]; then 
    history -a; 
    COMMAND=$(tail -n 1 $HISTFILE); 
    SQL="SELECT name from resolvables WHERE id IN (SELECT resolvable_id FROM named_capabilities WHERE name_id IN (SELECT id FROM names WHERE name LIKE \"$COMMAND\")) LIMIT 1;" 
    PACKAGE=$(echo $SQL | sqlite3 /var/cache/zypp/zypp.db); 
    if [ $PACKAGE != "-" ]; then 
    echo $COMMAND is not installed\; Try \"sudo zypper install $PACKAGE\" to install it.; 

Then you get similar behaviour:

benji@lcars:~> kopete
bash: kopete: command not found
kopete is not installed; Try "sudo zypper install kdenetwork3-InstantMessenger" to install it.

benji@lcars:~> amarok
bash: /usr/bin/amarok: No such file or directory
amarok is not installed; Try "sudo zypper install amarok" to install it.

benji@lcars:~> nothingprovidesthis
bash: nothingprovidesthis: command not found


However, the whole adding command to history and then re-reading seems like a really bad idea. Possibly a security hole if someone adds something malicious to .bash_history so it’s probably not a good idea to use this _. If anyone knows how to get the previous command in a better way please let me know. “fc” will return it, but not until after PROMPT_COMMAND has been executed it seems.

It also assumes that anything with exit status 127 is a command not found, which is probably not always true.

Also it doesn’t seem to work in other shells that are not bash.

Any better way to do this without command_not_found_handler() ?

February 09, 2008

One Click Install links from the command line.

I get asked occasionally whether it is possible to install some software from a “one click install” link from the command line. Well now it is.

I’m not entirely sure what peoples’ usecase for this is, but up until now the only answer has been to download the .ymp file, read it and follow the instructions manually.

Fortunately the one click install handler is implemented using YaST, and YaST not only makes it easy to make your interfaces display with Qt/GTK/Ncurses0, but also to add command line interfaces.

Several YaST modules already have command line interfaces. For example try running

  yast2 lan help

This made it quite easy to add command line support to the one click install handler.

Here’s a screenshot of it in action:

There is no support for doing anything interactive, like selecting optional software yet, but it should be functional.

If you want to try it out on openSUSE 10.3 simply

  1. Copy to /usr/share/YaST2/clients
  2. Copy to somewhere in your $PATH.
  3. Then run
      OCICLI <url>    

I need to remove some duplication of code with the existing graphical handler before committing to SVN, but it should be possible to include in future openSUSE versions if people want it.

[0] There’s a bug with the version in 10.3 that prevents it from functioning in ncurses mode, this should be fixed before 11.0

openSUSE presentations

While thinking about content for my talk at FOSDEM I was reminded that I never uploaded the slides for the talks I did at my local GNU Linux user group . I have now uploaded the slides, and they are also available here:

Also check out some of the other interesting talks that members of WUGLUG have given this year.

The description for my FOSDEM talk is at . If anyone has anything in particular they would like me to cover then please let me know.

February 05, 2008

openSUSE & desktop environment choice.

One of the strengths of openSUSE is that configuration tools written using the YaST platform do not have to be re-written to fit within a different desktop environment. For example here is the same printer configuration dialogue being drawn using the Qt/GTK and ncurses user interface toolkits.

If this configuration tool had been written as a KDE application it would appear out of place on GNOME, and if it were written as a GNOME application it would appear out of place in KDE.

The user interface for the One Click Install handler was implemented using YaST, which meant that GNOME users could benefit from it without having to depend on a KDE application KDE , GNOME . In other distributions new features may be focused on one particular desktop, and users of another desktop, may be left to wait until someone ports the features.

It also helps to allow the desktop teams to focus on working on KDE or GNOME rather than only writing and fixing configuration tools.

While this is a great strength, it is perhaps simultaneously a great weakness. Most other distributions which are targetted at end users have a default desktop environment, for example:

  • Ubuntu: GNOME
  • Debian: GNOME
  • Red Hat: GNOME
  • Mandriva: KDE
  • Freespire: KDE

etc.. (no need to list them all)

This is all very sensible, quite apart from allowing them to focus their development resource, it also allows them to market the distribution as a complete product. Take the main product description page for ubuntu for example , they are able to give a flavour of what the product looks and feels like because they recognise that the desktop environment is part of the product, perhaps the most important part. It also means users can install from an ubuntu install cd without having to understand what a desktop environment is. It also allows them to arrange deals to install the product on OEM machines.

Historically SUSE Linux was much the same as these others, the default desktop environment was KDE, there were personal and professional boxed sets of the SUSE Linux operating system. There was also an enterprise version SLD . SUSE Linux built up a significant userbase, primarily of KDE users. Even now, as of last count there are 70% KDE users vs 20% GNOME . These historical users being the most experienced, are perhaps the most likely to get involved with openSUSE development.

Since the Novell purchase of SUSE political pressures, presumably partly from ex-ximian people, led to the switch of the enterprise desktop product to GNOME as the default desktop environment. The thinking, apparently, was that SUSE’s niche as a great KDE based OS was insufficient and there was a better chance competing against Red Hat directly by copying exactly what Red Hat were doing.

After this the openSUSE default desktop was also changed, but not to GNOME, instead to have no default at all. Instead, users are now presented with a confusing step during installation , during which they have to choose which desktop environment they wish to use (Or an equally confusing download page if using 1cd install) . This is an impossible choice to make for someone who does not know what a desktop environment is, and the politically correct descriptive text does nothing to help. (Efforts have been made to improve the descriptions of the desktop environments shown during installation, and to show previews of each desktop, but these do not really solve any problems, only slightly alleviates them.)

This has the following implications:

  • The potential userbase is limited to those few who know what a “desktop environment” is.

Others won’t even get over the installation hurdle.

  • Reviewers assume the de-facto default desktop environment is GNOME.

As it is the default for the enterprise version, and also listed first. Consequently the poor quality GNOME desktop leads to bad reviews.

  • openSUSE can’t be marketed as a product, just a collection of packages and choices.
  • openSUSE can’t be installed on OEM systems without someone picking a desktop or forcing choice on users at first boot.
  • openSUSE is relegated from being a product to simply a playground for testing packages.

Quotes from the GNOME team such as “If you want a stable system, there’s SLED”, in addition to frequently broken GNOME packages in openSUSE releases would seem to support this view. SLED is the only remaining desktop product.

  • openSUSE quality decreases, can only be used by those who can fix the problems themselves.
  • Novell have more to develop and support as openSUSE and SLE diverge.

Many desktop features were added first to SLED10, and then moved to openSUSE. Development ends up having to be done twice, once on the enterprise products, and then on openSUSE. The more the codebases diverge the more work there is to support security & bugfix updates on both openSUSE and SLE products.

  • Only people who are interested in developing a distribution aimed at a geek niche will contribute to openSUSE.

None of which is good for the future of SUSE.

In my not-so humble opinion this situation is untenable, yet I can’t forsee any change. The de-facto SUSE Linux / openSUSE desktop has always been KDE by the user and developer base. Choosing GNOME would mean a loss of users/contributors as staunch KDE advocates move on. It possibly also means attracting few users as other distributors such as Red Hat/Fedora and Debian or Ubuntu already do much better jobs of shipping a GNOME desktop. Going back to KDE is unlikely to happen due to internal Novell politics & pressure from ex-ximian people. So most likely the situation will stay as it is now, with use slowly declining due to the problems above.

While some people have been complaining in recent weeks about kubuntu being a second class citizen to ubuntu, I see this as one of its greatest strengths. The alternative is like with openSUSE, the whole distribution ends up becoming the “second citizen”.

February 02, 2008

One Click Install Hot–Linking

I’ve noticed a trend of people hot-linking ‘One-Click-Install’ YMP files directly from on their blogs and news stories. While it’s great that people are including these it is worth considering whether it would be wise to take a copy of the YMP file and host it yourselves, or on openSUSE wiki, or somewhere else which can host static content.

If your web-host doesn’t understand the YMP mimetype a link directly to a YMP file will not work, you can work around this using “data:” URLs by creating a link as follows:



<a href="data:text/x-suse-ymu,">My Install Link</a>

The install links on are:

  • Auto-generated.
  • Subject to deletion/renaming at any time.

If you blog including a link taken directly from there then other people may simply copy it onto their blog/news site, and if the original disappears, or you need to make a change you end up with lots of broken or outdated links everywhere, even if you update your blog.

If someone points out a problem (need another package included, or a conflicting package removed, etc, then there’s no way to fix it. Additionally the YMPs generated by the buildservice are fairly inflexible at present as they are auto-generated from patterns. You might wish to alter it in a way not supported by the build-service.

Hotlinking is most likely to lead to headaches when the YMPs are complex, and frequently changing. Like the “install KDE4” links for example.

Hopefully that should help inform so as to enable you to make a decision as to whether to hotlink or copy the YMP.

Software Portal Progress

Some people have commented on the lack of public progress on the Software Portal Project so I suppose I should blog about it.

The goal of the project is to make it easy for users to locate and install software.

Some distributions are shipping with simplified application installers now (Such as Ubuntu’s “Add/Remove Applications”), these abstract away from the detail of packages and display only applications to the user. So, for example a package such as kdenetwork may contain multiple applications (kopete, knewsticker, ... ) and other applications such as amarok may be composed of multiple packages (amarok, amarok-xine, ...). The simplified installers therefore only show the applications themselves: amarok, kopete, knewsticker.

The software portal combines automatic detection of applications from package repository metadata, with user generated content. So it can import metadata from the main distribution repositories, buildservice repositories, packman, etc, and then detect applications which will then be browsable by the users. Users can submit new applications, and edit existing ones where the autodetection was not perfect. Users can attach screenshots, tags, comments etc to existing applications. Users will be able to install applications using a one click install link.

So how much is complete? We announced the project 9 months or so ago, progress has been slow as all those involved have been busy. Nevertheless there has been tangible progress.

Here are some screenshots

application view

application view


Now that Pascal has added support for users and roles all the core components are in place. Now it’s a case of Features features features. At some point we need to decide what features are necessary for an initial release.

I hope this has enlightened some as to what the software portal project is about, let us know if you have any suggestions or comments. There is a mailing list . Help is even more welcome than comments ;)

February 2008

Mo Tu We Th Fr Sa Su
Jan |  Today  | Mar
            1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29      

Search this blog



Most recent comments

  • Hey skx, how do you do that ? I run into the fu….. problem, that curl terminate with unspec. error… by David on this entry
  • With some minor changes this will also work for updating from 11.0 to 11.1. by skx on this entry
  • You are the man!!! Great work and good documentation! It worked without any problem for me. Thanks a… by Vany on this entry
  • didn't work for me. In fact killed the system. Have to download 11.0 and burn to dvd to fix it. by maybe windows on this entry
  • Will this method work for 11 => 11.1 ? by Erik Jakobsen on this entry

Blog archive

Not signed in
Sign in

Powered by BlogBuilder