Well, the “problem” is, that our Education team is currently more a team of technical specialists and many work is done behind the scenes without communication to “the outside”. So even if you did not hear from us for some weeks, we are still alive and coding!

Here are just a few examples, that are going on behind the scenes:

• Translation of the new openSUSE Education Portal is work in progress. Many thanks to our contributors Guillaume for the Français, Freek de Kruijf for the Nederlands, Sabarth for the Português, Gankov for the Русский (Russian) Portal translation!
• Kirill is currently reviewing all 425(!) packages in the Build Service Education project and submitting them to openSUSE Factory afterwards – so openSUSE 12.1 will come with a huge set of packages directly inside the official repository.
• Cyberorg is working on the next release of the openSUSE Edu Li-f-e DVD with the LTSP integration.
• Anubusg1 and many others (the project currently lists 44 maintainers) are doing the “normal” packaging stuff like upgrading and fixing packages for 12.1 (aka Factory)

The Desktop4Education project from Austria was again present at the Conference and gave a great overview of the current status of the project during their talk. Good to hear that the project is being frequently used as a reference case by the Austrian Federal Ministry for Education, Arts and Culture and as such promoted by them throughout Austria.

Talking with Andre Massing from the Simula Research Laboratory during his talk at the conference was quite interesting. Looks like the Science project might see some very interesting new packages in the next months. During the discussion, we agree that the Education and the Science project can share a lot of efforts in their project setups and organization. But they will stay separated (at least in the Build Service) as their audience is very different, even if they share some packages (which is currently done via links inside the Build Service).

– kde4-skrooge 0.2.9. Published in KDE:KDE4:Community and OpenSUSE:Factory:Contrib
– bleachbit 0.5.0. Published in openSUSE:Fatory:Contrib
– boinc-client. Just fixed gcc Errors. Published in openSUSE:Factory

now following an List from my last updated/worked Packages:

1. boinc-client 6.4.5 (last stable and recommended Version)
2. boinctray 2.3
3. kde4-skrooge 0.2.4 (also published in openSUSE:Factory:contrib and KDE:KDE4:Community)
4. libatlas3 3.8.2 (also published in Education)
5. libdbus++ 0.6.0
6. libtinyxml0 2.5.3 (also published in openSUSE:Factory:contrib)
7. libtktray1 1.1
8. lynis 1.2.3 (also published in openSUSE:Factory:contrib)
9. mountmanager 0.2.6 (also published in openSUSE:Factory:contrib and KDE:KDE4:Community)
10. necpp 1.2.6+cvs20070816
11. python-iCalendar 1.2 (also published in openSUSE_Factory:contrib)
12. qantenna 0.2.1
13. rkhunter 1.3.4 (also published in openSUSE:Factory:contrib)

Have a lot of Fun

A normal user, who wants to use one of these apps, might just choose to install the package and has the problem how to proceed afterwards. openSUSE sadly has no “post config” scripts like Debian based distributions – even the SuSEconfig scripts are deprecated. So all a packager can currently do is:

1. write a README.SuSE (which is already the case for many packages) and place it in /usr/share/doc/packages/<packagename>/README.SuSE explaning how to proceed
2. sugget what the user always wants to do and do it via %post-script after the installation of the RPM
3. combine 1&2 and point the user to a script in the README.SuSE
4. write a YaST module which can be started during installation or afterwards
5. any other option I missed (please inform me!)

For the Education project, I’m currently thinking about two ways to make the life of the admins easier.

First: think about “wrapper packages” around the normal packages. I’ll take moodle as example. The normal moodle package installs the php-scripts, an apache configuration and some other config stuff – but will not setup the complete moodle instance. So the user has to install the mysql database himself. An additional wrapper package can do this for him. This package comes with a SQL-Dump of the current moodle version (therefore requires the exact moodle version), and uses a stored mysql-root password to create a new database and insert the database-dump. If needed (for example: the user enables the “user LDAP-Auth wherever possible” checkbox in a (to be written) yast-edu module), additional tasks can be triggered by the wrapper package.

We can also think about calling a “generic” YaST module after installation of such a “needs postconfiguring” package. If we define a place (say: /var/adm/YaST/postinstall/) where packages can place a file containing some important questions to configure the application, and someone writes a YaST module which can be started, this would perhaps be “very cool”. If the user has entered his values, the YaST module can start one or more scripts (coming with the package) and feeds it with the entered values. The biggest questions for this solution:

1. When should this YaST module be started? IMO it could be enough to let the user start it manually and select the package he wants to configure. => No adaptions of the current workflows is needed. But perhaps there are other options (like calling it via “SuSEconfig”)?
2. Who can write such a module?
3. Who defines the config syntax?

Think about a file like this:

<package name=”moodle”>
<questionpack type=”string” action=”/usr/share/moodle/scripts/install_database”>
<question arg=”1″ type=”string”>What’s the database password?</question>
<question arg=”2″ type=”string”>What should be the name of the new database (suggest: moodle)?</question>
<question arg=”3″ type=”string”>What’s the username of the new database user?</question>
<question arg=”4″ type=”string”>What’s the password of the new database user?</question>
</questionpack>

<questionpack action=”/use/share/moodle/scripts/configure_auth_backend” type=”selectbox”>
<question arg=”1″>What auth-backend should be used?</question>
<answer value=”1″>ldap</answer>
<answer value=”2″>mail</answer>
<answer value=”3″>passwd</answer>
</questionpack>
</package>

I think, there’s room for many enhancements in this area – what do you think ?

Should/Could we produce something like a “Windows-Installer” for openSUSE? Or is it enough to provide special “wrapper packages”? Or is “what was hard to write, should be hard to install” still a valid answer?