= Debtags = '''Contact:''' JonathanLange <
> '''On Launchpad:''' Bug Bug:57418 == Rationale == (Based on [[https://lists.launchpad.net/software-store-developers/msg00092.html|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 purchase refunds could be reduced if USC could actively warn you that — for example — your computer doesn’t have enough memory. For this, requirements would need to be stored in a machine-parseable way. (Bug Bug:665249) 1. '''Maturity ratings.''' It should be possible for developers 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: https://launchpad.net/ubuntu/+spec/foundations-software-maturity-ratings|Blueprint]], bug Bug:708045) 1. '''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 Bug:475773, bug Bug:673226, bug Bug:591936, bug 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 [[http://debtags.alioth.debian.org/todo.html|edited separately]], reviewed, and converted to [[http://anonscm.debian.org/viewvc/debtags/tagdb/tags?view=log|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. (''See'' [[#bandwidth|why not a separate file]].) <> === Overriding Debian tags, and adding tags to Ubuntu packages === '''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.<
> '''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.<
> Ubuntu uses the `overrides` file to override data in various `debian/control` fields — seeds, support timeframe, Priority, and Section. The `overrides` file is generated from a variety of sources. Allowing Ubuntu-specific debtags would require adding one more source for the overrides file… '''As an''' uploader to a PPA<
> '''I want''' to be able to specify debtags for a package in the PPA<
> '''so that''' I can preview the effect the tags will have when the package is released to users. ''How would they do this?'' <> === 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 [[https://myapps.developer.ubuntu.com/|MyApps]]. My``Apps 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: || ||Without tags (MB)||With tags (MB)||Projected, with every package tagged||Extra|| ||Uncompressed ||35 ||37 ||38.3 ||10% || ||bzip2 compression (default)||7.4 ||7.6 ||7.7 ||4% || ||xz compression ||6.8 ||7 ||7.1 ||5% || Unfortunately we have no data on whether, for example, downloading the `Packages` file is a step that computers often fail on when installing software updates. In the meantime, though, Launchpad should publish debtags in the `Packages` file rather than using a separate file. === 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? ==