Copr design - being all things to all people

Lots of things happened this third Fedora Summer Coding week. Most people are already wrapping up, but I feel like I’m still at the beginning.

The biggest accomplishment of this week has got to be the fact that we (I and my mentor, Toshio) settled on a stable design for representing Coprs, Repos and their relationships. It was harder than it might seem, since we’ve got all these different entities in Fedora: we’ve got repos that you could look at as being either a directory with a release and an architecture or a repofile that is the same across releases and arches. When talking about releases we’ve got Fedora releases (e.g. Fedora 13, Fedora 14) and then we’ve got the packages for other distros with their own releases: EPEL and OLPC.

Now, on top of all of this we’ve got Coprs and (at least) two groups of users for the API: the end-users of the Coprs – the people that install the repos and the packages and the developers of the packages in the Coprs. The end users shouldn’t have to deal with the intricacies of the Copr/Repos/Releases model; ideally they’d just have one big button per the distribution they’re using, so they can install the repo once and have it work even after they’ve upgraded their distro three times or reinstalled five times (which is sort of how a repofile works). The package developers on the other hand could get hurt by the differences between different distro releases and their different packages – when depending on different package versions for example.

So finally we get to Coprs which should basically be a collection of packages that are available for one or more distros with each one having one or more releases. The package maintainer gets to create a Copr and choose a number of releases which they want to support with that Copr. One Copr can depend on as many other Coprs as needed. When the maintainer creates a Copr, the Copr App will automatically create repos for all of the specified releases and for each of the architectures that are supported by the buildsystem.

Everything I said until now is already implemented at the level of the TurboGears App which will provide the API for the web interface and any number of JSON clients. The schema is built and the database insteraction works fine, but repos don’t actually get created, because that’s not part of my proposal and will be handled at a different level. Oh and it’s all unit tested!

This week wasn’t just designing and building though, I spent a lot of time digging through TurboGears2 and its sub-packages’ documentation for things that should make the code simpler: raising JSON errors from nested functions, sending list arguments to JSON functions via WebTest post requests and even returning a flat list from a SQLAlchemy query on a single table column. All of these things seem to me like they should already be implemented and easy to use which makes me waste time searching for them. In fact they either are bugs or require coding them myself (at least from what I understand so far). I’ll have to investigate further, especially now since the weekend is over and I hope there’ll be more people answering questions on IRC and on issue trackers.

This next week I’ll mostly start worrying about what happens when a package maintainer submits a package to be built and that package has the right dependencies available in some releases, but not others, even though the Copr should support all of them. Will she have to submit different SRPMS for each release or should the Copr have the same version of the package in all of its releases? This will be a matter of settling upon a contract that the Copr provides its users and how uniform the Copr’s content has to be.

Fedora Summer Coding! Yay!


Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.