XOE Developers Guide v1.0: A guide to application development within the XOE framework | ||
---|---|---|
Prev | Appendix A. Reference Material | Next |
The information inside a package description is used for three general purposes:
Every package has a name and a version. If the package is built for a specific architecture, the name must end in "-native". In this case, the package also has an architecture attribute (eg, i386 or arm).
The name, version, and architecture of a package make up the Package URI. If two packages have the same URI, they are assumed to be identical.
Inside a package description, a package maintainer may specify dependencies on other packages. A dependency may specify a specific package or a type of package. No package may be installed if any of its dependencies are not met.
Likewise, a package may contain conflicts. No package may be installed if it conflicts with another installed package.
Dependencies and Conflicts are matched by Provisos. A proviso specifies some outward characteristic of a package. All packages have at least one proviso that specifies the name, version, and architecture (for native packages) of the package. Packages that contain services will contain a proviso for each service they install.
This means, for example, that it's possible to depend on a specific package name, a specific version of a specific package, or a range of versions. It's also possible to depend on a certain type of service (eg, a protocol handler for Gopher)
Packages may also contain information meant to be read by users. This should describe, in a human language, what the package provides. Examples of the types of information you can include here:
A friendly name (ie, "HTTPS Native Libraries" vs "libhttps-native")
A short summary
A longer, multi-paragraph description
Keywords (these can be searched on)
Copyright information
Website
Maintainer name/email address
Vendor
In addition, a package can have an optional task attribute. If set to true, the package will be presented to the user in "basic" searches. If it is unset, or set to false, the package will only be available in advanced searches. This can be used to "hide" packages that the user should never manually install. For example, there's no reason to install libhttps-native by itself (without libhttps). Several other packages are necessary in order to make these packages useful. The solution is to create a task-https package. This package contains dependencies on libhttps, libhttps-native, libssl-native, and default-certificates (which contains the X509 certificates for Verisign, etc..). task-https has a task='true' attribute, all the other packages are task='false'. When the user enters the keyword "https", they will only see the task-https package, yet installing it will automatically install all the other packages.