Packages other than RPM packages
$
publican package
command, Publican generates a tarball that you can use to build a package to distribute through different package manager software. If you run publican package
on a computer on which rpmbuild is not installed, Publican still generates the tarball, even though it cannot then generate an RPM package from that tarball.
Note — Customizing output
publican.cfg
) allow you to control many aspects of the way in which a document is presented and packaged — refer to Section 4.1.1, “The publican.cfg file”.
--config
to specify which configuration file (and therefore which set of parameters) to use in a particular build, for example:
$
publican package --lang hi-IN --config community.cfg
/usr/share/doc/
, the location specified by the Filesystem Hierarchy Standard (FHS) for ‘Miscellaneous documentation’.
[3] The desktop RPM package also contains a desktop file, to be placed in /usr/share/applications/
. This file enables desktop environments to add the installed document to their menus for ease of reference by users. By default, the menu item appears under → on the GNOME desktop. To customize the placement of the menu item, create a documentation menu package to supply .directory
and .menu
files and set the dt_requires
and menu_category
parameters in the publican.cfg
file to require this package and supply the appropriate menu category. Refer to Section 4.8.1.3, “Desktop menu entries for documents”
web_formats
parameter. The value of this parameter overrides the default formats that Publican packages. For example, to publish the document only as single-page HTML, PDF, and text, set web_formats: "html-single,pdf,txt"
/var/www/html/
, a common document root for web servers. Note that the web SRPM package generates both a web binary RPM package and desktop binary RPM package.
.directory
) file that provides metadata about the new submenu.
.menu
) file that defines the position of the new submenu within the menu.
.directory
file for Publican-generated documentation is as follows:
[Desktop Entry]
Name
parameter, set to the name of the submenu that you want to place under the menu.
Name
parameter, in the format Name[language_code]
where language_code is a language code in glibc format, not the XML format that Publican uses for language codes.
Comment
parameter, set to a description of the new submenu.
Comment
parameter, in the format Comment[language_code]
where language_code is a language code in glibc format, not the XML format that Publican uses for language codes.
Type
parameter, set to Directory
.
Encoding
parameter, set to UTF-8
.
Example 4.5. Example .directory file
menu-example.directory
illustrates the structure of a desktop entry file.
[Desktop Entry] Name=Example Name[fr]=Exemple Name[it]=Esempio Comment=Example Documentation menu Comment[fr]=Exemple d'une menu de documentation Comment[it]=Esempio di un menù di documentazione Type=Directory Encoding=UTF-8
/usr/share/desktop-directories/
<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN" "http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd">
<Menu>
, that contains:
<Name>
element with the content Documentation
<Menu>
element that in turn contains:
<Name>
element with the content Documentation
(just like the root element)
<Directory>
element with its content the name of the desktop entry file you created, for example:
<Directory>menu-example.directory</Directory>
<Includes>
element with the content X-category_name
, where category_name is an identifier for the documents that will be grouped together under this menu entry. For example:
<Includes>X-Example-Docs</Includes>
Example 4.6. Example .menu file
menu-example.menu
illustrates the structure of a desktop menu file.
<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN" "http://www.freedesktop.org/standards/menu-spec/1.0/menu.dtd"> <Menu> <Name>Documentation</Name> <Menu> <Name>Documentation</Name> <Menu> <Name>Example</Name> <Directory>menu-example.directory</Directory> <Include> <Category>X-Example-Docs</Category> </Include> </Menu> </Menu> </Menu>
/etc/xdg/menus/settings-merged/
menu_category
parameter in its publican.cfg
file to match the content of the <Includes>
element in the corresponding desktop menu file. For example, consider a desktop menu file that contains the element:
<Includes>X-Example-Docs</Includes>
publican.cfg
file should contain:
menu_category: X-Example-Docs
Important
__LANG__
with the current language. This allows menus to be customized on a per language basis.
menu_category: X-Example-Docs-__LANG__
defaults.cfg
file or overrides.cfg
file of a brand so that all documents built with that brand are grouped into this submenu automatically without you having to set the menu_category
parameter in each document.
dt_requires
parameter in the document's publican.cfg
file. For example, if you ship a desktop menu package named foodocs-menu, set:
dt_requires: foodocs-menu
defaults.cfg
file or overrides.cfg
file of a brand so that all documents built with that brand require the same desktop menu package.
$
publican package
command$
publican package --lang=Language_Code
command to package documents for distribution in the language that you specify with the --lang
option. Refer to Appendix G, Language codes for more information about language codes.
$
publican package
with no options other than the mandatory --lang
option, Publican produces a web SRPM package. The full range of options for publican package
is as follows:
--lang
languageIncomplete translations
ignored_translations
parameter in the document's publican.cfg
file. The package will be named appropriately for the language, but will contain documentation in the original language of the XML rather than a partial translation. When translation is complete, remove the ignored_translations
parameter, increase the release number in the Project-Id-Version
field in the Book_Info.po
file for that language, and generate the package again. When you distribute the revised package, it becomes available to replace the original untranslated package.
--config
filenamepublican.cfg
file.
--desktop
--brew
--scratch
--brew
and --desktop
options, specifies that an SRPM package should be built as a scratch build when sent to Brew. Scratch builds are used to verify that an SRPM package is structured correctly, without updating the package database to use the resulting package.
--short_sighted
version
in the publican.cfg
file) in the package name.
Omitting the software version number
--binary
$
publican package
command, Publican outputs completed SRPM packages to the document's tmp/rpm
directory, and completed binary RPM packages to the document's tmp/rpm/noarch
directory.
productname-title-productnumber-[web]-language-edition-pubsnumber. [.[build_target].noarch].file_extension
.
publican.cfg
) to supply the various parameters in the file name, and then information in the Book_Info.xml
file for any parameters missing from the configuration file. Refer to Section 4.1, “Files in the book directory” for details of the parameters used in these files. Additionally, note that:
-web-
between the product version and the language code.
.src.rpm
but binary RPM packages have the file extension .rpm
build_target.noarch
before the file extension, where build_target represents the operating system and version that the package is built for as set by the os_ver
parameter in the publican.cfg
file. The noarch
element specifies that the package can be installed on any system, regardless of the system architecture.
--short_sighted
option removes the -productnumber-
from the package name.
Project-Id-Version
parameter in the Article_Info.po
or Book_Info.po
file. This release number is specific to a particular language and bears no relationship to the release numbers of the same document in the original language or any other language.
$
publican package
command — Example usage$
publican package --lang=cs-CZ
$
publican package --desktop --lang=cs-CZ
$
publican package --binary --lang=cs-CZ
$
publican package --desktop --binary --lang=cs-CZ
$
publican package --desktop --short_sighted --lang=cs-CZ