Home Home > 2009 > 11 > 02 > OBS Attribute System (not only for maintenance!)
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

OBS Attribute System (not only for maintenance!)

November 2nd, 2009 by

People who follow the openSUSE Build Service (OBS) developments might know it already, we work on an attribute system for OBS. But what it is good for at all ?

Our current driver is to enable every OBS user to do maintenance for packages in the maintained products (which are currently openSUSE 11.0, 11.1 and a few days 11.2). The maintenance concept itself is described in a very first draft here

However, the attribute system is way more powerful and can be used to store all kind of informations, attached to projects, source packages or even binary sub packages. The important thing here is that the attribute types have own permission rules. So it is for example possible to edit data in projects like openSUSE:11.1 or Fedora:9 which are usually read only.

A simple example is the OBS:Screenshot attribute, as you might guess you can attach references to screenshots to it. Every maintainer or bugowner has write access to it, this means if you are the bugowner of a package, you store this kind of informations not only in your projects, but also in the openSUSE:11.X project packages.

There is also the openSUSE:Playground attribute type created, just for you, when you like to play with this. Btw, the current available attribute types can be requested via “osc meta prj OBS”. And when you use the osc 0.123svn from svn trunk or openSUSE:Tools:Unstable Project, you can even check single attributes in different ways or create them.

For example:

osc meta attribute openSUSE:11.2 # Shows the attributes of the openSUSE:11.2 project
osc meta attribute home:adrianSuSE --attribute openSUSE:Playground --create # just creates the attribute in my home project
osc meta attribute home:adrianSuSE zphoto # returns empty, since the package hasn't the attribute.
osc meta attribute home:adrianSuSE zphoto --attribute-project # returns with attribute, since it falls back to the project

# stores two values (World Domination and fast) inside of the attribute:
osc meta attribute home:adrianSuSE --attribute openSUSE:Playground --set "World Domination,fast"
osc meta attribute home:adrianSuSE # shows all attributes in my home

osc search --attribute openSUSE:Playground # finds all packages in all projects with the openSUSE:Playground attribute
osc search --package zphoto --attribute openSUSE:Playground # finds all zphoto packages in all project with the openSUSE:Playground attribute

Okay, Okay, all that sounds not horrible sexy when you read it first. But imaging the possibilities. Each team or use case can get their own attributes. They decide what to store in which package, independend if they can modify the sources of project or not. So a team can easily mark packages for any kind of purpose (to fix bugreport 1234, to complete their product Z, to show the state of the packages on web page X, …).

The “osc mbranch” command from the maintenance concept shows also the power of this. You do not need to know where all instances of your package, just tell the server that you need to work on it and the server collects them all.

Please note that the API for the attribute system still might change until OBS 1.7 gets released, we may even need to remove the attributes (even though this is not planned). However, the version running at opensuse.org should be ready to play with this system. And I _really_ would like to hear any kind of feedback, ideas or requests. Can you please comment here, what you can imaging, what else you can use this system for ?

Thanks a lot !

PS: New attribute types can be defined only by the administrator atm, but I am really happy to create any kind of attributes for you, even though you just want to play with it!

Both comments and pings are currently closed.

4 Responses to “OBS Attribute System (not only for maintenance!)”

  1. RedDwarf

    Would it be a good place to store the info from http://gitorious.org/opensuse/osc-plugin-collab/blobs/master/server/upstream/upstream-tarballs.txt ?
    A way to know which packages are outdated (compared to upstream) is something I really miss from the OBS. I think having to submit new entries to gitorious is the cause it’s not used more.

    And I expect software managemente tools to start showing those OBS:Screenshot…