Duncan Mac-Vicar P.

We have cleaned up the main pages of libzypp and satsolver, mainly to introduce a new feature.

Since today, there is developer documentation generated on every svn build from our cruise control system (continuous build), available for trunk and branches.

ZYpp documentation has already qute some articles and the API is very good documented, still, it will be enhanced in the following months to take advantages of having the documentation always available. SP2 branch documentation will be available soon.

For SAT solver, we have moved the existing documentation into the Related pages of the generated documentation (which already contains very useful articles) and we will do every possible effort to document the API too (which is almost empty right now :-/ ).

Yesterday I sat together with Stefan Haas in front of the whiteboard and analyzed the specification of the DSP1023 (Software Inventory) and DSP1025 (Software Updates) CIM profiles, from the DMTF.

Our goal was to understand it, and therefore we tried to map the concept to the knowledge we already have, which is Linux software management (which in turn can be reduced almost to packages :-). Here are our notes:

(For simplicity, I am skipping the CIM_ prefix for all classes)

Packages

Packages are represented as usual NVRs (name, version, release) using the SoftwareIdentity class.

The url of the package is represented associating the SoftwareIdentity with url instances (SoftwareIdentityResources) trough a SAPAvailableForElement association. Products, subpackages and components can be modeled by using OrderedComponent class, which references the component and one member per instance.

One can associate hardware (or any managed element) with software using ElementSoftwareIdentity

Repositories

Repos are modeled by using SystemSpecificCollection and associated via HostedCollection to a system (that seems to be the local computer).

Packages are associated to the repository via the MemberOfCollection class.

Installed packages are represented by instances of InstalledSoftwareIdentity (which references the ComputerSystem where it is installed).

Groups, Patterns

Just another software identity (for the group itself), and references the grouped identities using OrderedComponent instances (which has two fields, the GroupComponent and PartComponent, which reference the respective instances).

Dependencies

If the target software does not have and instance, a SoftwareIdentity is created and isEntity set to false (kind of named dependency) For dependencies that exists software collection, then OrderedDependency is instantiated for each dependency and Antecedent and Dependent is filled)

For installing the packages, a SoftwareInstallationService is needed. Packages can be installed calling installFromSoftwareIdentity() (name, version release instance) or installFromByteStream() (like an rpm package).

To define an installation service, the SoftwareInstallationService class need to specify what it supports by instantiating SoftwareInstallationServiceCapabilities (which has properties like the supported URI schemes), and then this capabilities are associated back to the service using ElementCapabilities.

To define whether a package is compatible with a given target, one uses the TargetTypes array in the SoftwareIdentity class.

If a SoftwareIdentity is available and there is some SoftwareInstallationService that is compatible (or capable) of installing it, a instance of the ServiceAffectsElement needs to be instantiated.

Before actually installing or updating, the client checks if a SoftwareIdentity can be installed on a element, using the CheckSoftwareIdentity() method on the SoftwareInstallationService. You give this method the software itself, the collection and the target element. You get back a InstallCharacteristics with the details (for example if you need to reboot after installing or not).

Once you start the operation using InstallFromSoftwareIdentity(), you get back a Job instance that represent the task. Also true for InstallFromByteStream(), but here you pass an Image instance instead of a SoftwareIdentity. There is a similar InstallFromURI operation too. (jobs are only returned if the service has async capabilities).

The client can pass options to the install operation using InstallOptionValues.

TODO: figure out ElementSoftwareStatus more.

Additionally, you can see how HP has implemented the inventory profile with rpm. It has some useful information about which rpm tags belong to which classes properties for example.

If you own a Blackberry from Vodafone Germany, you may be able to update to OS 4.5 depending on your model. I did the update yesterday, and it went smooth. You will need:

• Windows machine, as the update is done from the desktop manager
• The right firmware update for your model.
• You need to re-activate against the Enterprise Server in case you use BES. Contact your administrator for that.

You get lot of improvements against 4.2:

• Better browser. Mouse cursor to navigate.
• HTML mails
• Video camera.
• Some Media Player enhancements.
• Decent fonts.
• Documents to go. I can now even open pdfs from mail.
• Lot of user interface improvements. It looks nicer.
• Free/Busy calendar lookup.

(note, features depend on your device model)

Morning

Did not start the day in a good way. I buy mobicards every month so I have full access to the public transport system. I buy them via the internet, so I get an email when it is about to run out, and with one click I get the form to order another one by mail (even with the date range pre filled).

Today I took the straßenbahn (tram), and suddenly the guy next to me transformed itself in 1 second from a civilian to a public transport control employee, and asked me for my ticket. I took my mobicard from my pocket and showed it to him. He nods but after a second he comes back and ask “let me see it again”. He looks again and points out it starts on 12.11 and today was 11.11. No problem, last month one is behind that one (the whole year cards are there). He looks the old one and points out “This one ends at 10.11″. I could not believe it, I did not even realize. Usually I just click OK-OK when buying them. I got a ticket. Luckily the checkbox marked was not “pay 40€” but “Go to the headquarters to clarify” (which still means they could fine me). Of course that means wasting half a morning not counting the time I lost already over the tram (not being able to get out in the right station). If I get fined after buying mobicards every month for years it would be really ironic.

ZYpp

In the office we had the typical “first media” blocker. Luckily Michael found the bug really quickly. Later I wanted to test the fix using linuxrc magic driverupdate tricks I have learned in the past weeks. However it did not work: Linuxrc can use rpms as a container format, but still expects the driverupdate directory structure. Bah, world was not that cool as I thought. Met with Michael and Steffen about it. Steffen realized that it would not be a bad idea to try the rpm first as a driverupdate, and if no driverupdate is there just unpack it in the system (and promised to implement it) That sounds good, easy testing. Happy.

YaST

autoYaST

Katarina wrote a really nice tutorial that explains how use autoYaST to apply a configuration to a running system. Uhm. Looks like an XML API. Wow. Couldn’t we use it for our YaST web service?. Talked with schubi about it. While the command line interface has higher level, exposing this interface would make sense too, because it will offer automatically almost all autoYaST power.

Partitioner

The new YaST partitioner, on which Katarina, Arvin, Matthias and Martin worked really hard during the Code11 cycle got a pretty nice review here. Give it a look. And give the guys feedback. I am sure lots of things can still be improved!.

YaST releases

Stano is reviving the discussion about whether to make independent of openSUSE YaST releases. I talked about this topic with Zonker just after he started as community manager.

I think it would be a pretty good move. Also a big challenge. It would mean a challenge not only for us the YaST teams but also for other internal and external stakeholders.

Right now a new YaST package submission (same with libzypp) is more or less tied with the development of features or some project manager sitting next to your chair to get a blocker fixed for an openSUSE release. Things would change if the distribution’s team would need to take the last released YaST and take patches, forward ports, backports, etc.

Also it would be a challenge for us. Most of YaST testing happens on a openSUSE release. We have lot of ideas on how to improve our automated testing and this would require develop them further. Also I think an approach like this would facilitate making YaST less distro-dependent.

Another point I like of the approach is that it would force us to have a better process to define our core-platform (ir order to be able to release it separately). Right now I see it a bit chaotic: APIs are born in modules, and as soon as they are used by more than one module, they land in the wildcard yast2 package. Something I really don’t find very convenient. APIs should be reviewed with more care and packaged by the area the API covers.

Still and interesting topic and material to innovate!

duncan@tarro:~> xmms

The program 'xmms' can be found in the following package:
  * xmms [ path: /usr/bin/xmms, repository: zypp (packman) ]

Try: sudo zypper install xmms

bash: xmms: command not found
duncan@tarro:~>

made possible by Scout.