Frank Karlitschek is joining us here in Nürnberg to work with us through the Hackweek. First project is to build and integrate an interface where webapps like www.kde-apps.org can get information from about binary packages that exist on the openSUSE Buildservice. That will make it very easy for upstream developers who build their package for several distros in OBS to get a list of available binaries in the application directory application. In kde-apps.org which will use this first you just need to enter the name of OBS project and package and the download links for rpms or deps will appear automagically. That takes away the pain to maintain lenghty lists of links to rmps 🙂
The specification is in the Wiki – Buildservice Concepts. Comments are welcome.
Both comments and pings are currently closed.
A few comments
* There is considerable overlap between the information in your “Binary Package Information” and what can be specified in the YMP. In fact they’re pretty much identical except for format YMPs also can have the binary details for multiple distributions in one file. OBS doesn’t currently generate them like this though. It is nice having the full URI to the package in the file though. If you’re creating a new format, it might be worth splitting the distribution and version into separate attributes. Having them concatenated has led to several issues with YMPs.
* We are currently generating something very similar for http://software.opensuse-community.org
* In addition we allow users to select the preferred vendor for an application and the binary packages that should be installed by default. Which is useful when some applications have literally dozens of vendors and hundreds of packages in OBS.
* The biggest challenge we’ve found producing the above from OBS metadata is not identifying what binaries are available but tracking changes. At present the rate of change is very high in OBS, and only full new metadata is published when one or two packages in a repo change. So we have to diff the new metadata against the information in our database. Having updates pushed to us would be a lot more convenient.
* Another challenge is the rate of repository change in OBS. If there’s one thing people like doing in OBS it’s moving stuff around. Determining the difference between “The repo is unavailable” and “The repo has moved somewhere” is difficult when the OBS just 404s instead of 410ing or 301ing. How will you address this for integrators?
In summary, I think the main problem at the moment is not the lack of information available from OBS but organising that information.
Better yet, make the distribution=”” a hyperlink to the distribution metadata. And make the project=”” a hyperlink to the project metadata. I think that would be more restful.