Skip to content

Packaging requirements

Octavio Alvarez edited this page Aug 29, 2013 · 1 revision

This document is a draft and is subject to change. Suggestions and comments are really really welcome. Discussion is encouraged through the Talk:Packaging_requirements page or the Support channels.

Changes to this page can be monitored through the offered RSS feed and announced through the different Support channels.

Table of Contents

Introduction and scope

This is a list of requirements for packages to be accepted as official Superkb and published in the Superkb download sections of its websites.

This is different than those packages that are to be uploaded to an "official repository of a distribution". However, for those packages these rules apply as recommendations.

Scope of a package

Packages must be as distribution and version-specific as possible. A package should be different for Ubuntu than for Kubuntu. The reason behind this is that both have different default software and file locations and thus default key bindings may be different. Under this context, Ubuntu is different than Debian; Ubuntu is different than Kubuntu; Ubuntu Jaunty Jackalope is different than Ubuntu Karmic Koala.

Sane default behavior

Packages must contain an /etc/superkbrc file for default configuration. This must include the best possible configuration for the distro defaults, including a WELCOME_CMD, FEEDBACK_HANDLER, DOCUMENT_HANDLER, default KEY bindings, etc.

Default KEY bindings in /etc/superkbrc should follow the default installation for that distro/version with the default desktop environment. If the distribution is 100% desktop agnostic, look harder for a default. For instance: Debian Unstable (Sid) appears to be desktop agnostic, but Debian Unstable (Sid) installation depends on Debian Testing which provides GNOME as the default when "Desktop environment" is chosen at installation time; therefore, the default bindings for Debian Unstable (Sid) should be based on GNOME.

Sane default key bindings

Suggestions for default KEY bindings convention :

  • c = Calculator
  • n = Notes or plain editor
  • l = Lock screen
  • Home = Home directory
  • i = Internet Browser
  • F5 to F7: Word Processor, Spreadsheet, Presentator
  • F4: should not be bound by default.
  • F12: Terminal.
  • PrScr: Screenshot taker.
Default KEY bindings in /etc/superkbrc must include corresponding feedback strings.

Dependencies

Proper dependencies must be put in place. In addition to the usual dependencies for the binary itself, don't forget dependencies on programs referenced by the configuration files (like /etc/superkbrc). For example, if under Debian you use nofity-send for FEEDBACK_HANDLER, the package must depend on libnotify-bin.

Development packages (like -dev or -devel) SHOULD NOT be part of the dependency list. These are only needed for compilation (which to be avoided is the purpose of the package itself).

Package contents

The package must include:

  • The Superkb binary in /usr/bin/
  • All required Superkb modules (according to the build configuration) go under /usr/lib/superkb/
  • The manual page for Superkb, in /usr/share/man/man1/ (or whatever directory works best).
  • All sample files under /usr/share/doc/samples/.
  • The build configuration file should be placed as /usr/share/doc/superkb/build-configuration.
  • License should be placed as /usr/share/doc/superkb/LICENSE.

Version conventions

For packages based on a release: the "upstream" must match the release.

For packages based on development snapshots: the "upstream" must follow a format that indicates the latest release as a "base" and adds the time semantics for the package manager to recognize the version as incremental over time. For example: 0.20+git:YYYYMMDD is OK if the package manager recognizes 0.20 < 0.20+git:20100101 < 0.20+git:20100201 < 0.21 < 0.21+git:20100301. Otherwise, upgrading operations will break.

Architectures

For a package to be accepted for a particular distro/version combination, a package maintainer must provide versions for both, i386 and amd64 architectures.

Testing

Packages must be tested under the intended platform and version using the minimum depended versions of the libraries.