Debtags

Contact: JonathanLange
On Launchpad: Bug 57418

Rationale

(Based on a message from 2011-06-22.)

For three main reasons, Ubuntu Software Center needs access to arbitrary key-value data for each package — whether the package is in the Ubuntu archives, a PPA, or Independent (For Purchase and ARB) channels. Debtags are the existing mechanism for this in Debian, and adopting it in Ubuntu would allow reuse of tags that have been applied in Debian.

Most important first:

1. Hardware requirements. Especially for games (but also for graphics-intensive software like Google Earth), it is useful for people to know that software does not work with a particular kind of video card, or that it requires a particular amount of memory. This could be included as free-form text in the package description, but it would be better implemented in a machine-parseable way, so that — for example — USC could warn you if you don’t actually have enough memory. (Bug 665249)

2. Maturity ratings. It should be possible for people to filter software based on how much violence, horror, sex, degrading language, etc it includes. This requires packages to be rated on those axes, and for those ratings to be easily accessible without downloading the package. (Blueprint, bug 708045)

3. Better categories. Currently USC’s categorization system is based on categories in .desktop files, and Section: values in debian/control files. Some of the categories are awkward, and several of them would be much more useful with subcategories (particularly “Fonts”, “Office”, “Sound & Video”, “System”, and “Themes & Tweaks”). (Bug 475773, bug 673226, bug 591936, bug 602206)

Stakeholders

• mvo, Consumer Applications, Ubuntu Software Center
• XXX - others?

User stories

Inheriting Debian tags

As an Ubuntu developer
I want Ubuntu’s tags, for a package synced from Debian, to include any tags set by Debian contributors
so that the tagging does not need to be redone.

In theory, tags can be included by the package maintainer using the XB-Tags: or Tags: field in debian/control. In practice, few package maintainers do this, because they’re unfamiliar with the vocabulary. Tags are instead edited separately, reviewed, and converted to a separate file that is then merged into Debian’s Packages file.

So, when an Ubuntu package is synced from Debian, Launchpad needs to see whether Debian’s tags file includes debtags for that package; and if so, merge them into Ubuntu’s Packages file.

Overriding Debian tags (no work required)

As an Ubuntu developer
I want to override tags set by Debian contributors, without maintaining a diff against the package
so that I can sync the package without worrying about undesirable effects in Ubuntu Software Center.

Ubuntu already uses the overrides file to override data in various debian/control fields. No Launchpad changes are required for this to work for the Tags: field as well.

Adding Ubuntu-specific tags

As an Ubuntu developer
I want to add debtags to an Ubuntu package that isn’t in Debian
so that it can be classified and categorized in all the same ways.

Without a Launchpad UI, how would this be done? In the overrides file?

Adding tags to an independent package (no work required)

As an independent software vendor
I want to classify my application by precise subcategory, maturity rating, etc
so that it shows up in Ubuntu Software Center in the appropriate way.

This does not require UI in Launchpad; the UI belongs in MyApps. MyApps can store the tags using Tags: in debian/control, so that Launchpad does not need to do anything special to preserve it.

Constraints and Requirements

Should an archive’s debtags be in the Packages file, or a separate file?

In Debian currently, debtags are stored in the Packages file. An alternative for Ubuntu would be to use a separate Tags file. This would save bandwidth when checking for updates, or when doing package management on a server where debtags are uninteresting. But it would require more work in Launchpad and (to a lesser extent) in Ubuntu Software Center.

So how much bandwidth would it save, exactly? We can use Debian as a guide. Currently, Debian’s Packages file contains tags for 21 000 out of 35 000 packages. The size of their Packages file is:

Must

Nice to have

Must not

• Maintain tags as a file on the filesystem, ala package-arch-specific override
  • This apparently "creates nightmare in the publication code"

Out of scope

Success

How will we know when we are done?

How will we measure how well we have done?

Thoughts?