Automating publishing
From FedoraProject
This page tracks progress towards implementing a fully automated publishing process for the Fedora Documentation Project.
Contents |
Background
Formal Fedora documentation is authored in DocBook XML and transformed into multi-page HTML, single-page HTML, PDF, and EPUB by our publishing tool, Publican. Publican also maintains the Fedora documentation site (docs.fedoraproject.org) and automatically generates and updates the navigation menus in each language.
At present, the entire documentation suite hosted at http://docs.fedoraproject.org resides in a Git repository to which certain members of the Documentation Project (members of the docs-publishers group) commit changes. The webserver publishes whatever is in that repo.
This is a vast improvement over our previous process, but Publican includes features that make publishing even easier and more robust, since Publican is designed to package documentation in RPM packages to install on a webserver. Chapter 6 of the Publican Users' Guide provides an overview of the mechanism.
Important -- note that since the webserver runs Red Hat Enterprise Linux 5, the documentation packages need to be built for Red Hat Enterprise Linux 5. Publican is also designed to build documentation to install for desktop use, but this is a separate set of considerations and not the aim here.
Steps to automate publishing
Install Publican 2 on the webserver
Publican 2 is the first version that includes the web publishing components. However, Publican 2 has a number of dependencies that are either not in Red Hat Enterprise Linux 5 at all, or which are in Red Hat Enterprise Linux 5 in versions too old for Publican 2. While we could build dependencies in the former group in EPEL, we cannot build dependencies in the latter group in EPEL since EPEL packages must not update packages in Red Hat Enterprise Linux, only provide packages that are not shipped at all.
To install Publican 2 on the webserver, we need to
- build the dependencies not in el5 for EPEL
- build the dependencies too old in el5 for dist-5E-epel-infra.
- find a solution to using fonts-chinese-zysong
- build Publican 2 and the Fedora brand package for dist-5E-epel-infra.
Dependencies not in el5
-
perl(Config::Simple) -- sixy (stable) -
perl(DateTime::Format::DateParse) -- rlandmann -
perl(File::pushd) -- mmaslano (stable) -
perl(Locale::PO) -- iarnell -- (stable) -
perl(Syntax::Highlight::Engine::Kate) -- mmaslano (stable)-
perl(XML::TokeParser) -- iarnell (stable)
-
- [fop -- nb/lkundrak (testing -- installs, but depends on batik and newer xml-commons-apis)]
-
xmlgraphics-commons -- nb/rlandmann (stable)-
jakarta-commons-io -- pcheung/rlandmann (stable)
-
-
- [dep for batik]
-
jython -- overholt/rlandmann (stable)-
ht2html -- mjakubicek (stable) -
libreadline-java -- akurtakov/rlandmann (stable)
-
-
- [deps for perl(Makefile::Parser)]
-
perl(IPC::Run3) -- corsepiu/rlandmann (stable) -
perl(Makefile::DOM) -- ryanlerch/rlandmann (stable)
-
Dependencies to update in el5
- perl(XML::LibXML) (built)
- libxml2 (built)
- perl(XML::LibXSLT)
- libxslt
- perl(XML::TreeBuilder) (built)
- docbook-style-xsl (built)
Also these packages that cannot be built for el5 because of a dependency that is too old in el5:
This package builds for el5 but cannot be installed because of dependency problems:
- fop (depends on batik and xml-common-apis) (built)
fonts-chinese-zysong
The EL5 version of Publican 2 depends on fonts-chinese-zysong, which is shipped only on the Red Hat Enterprise Linux 5 supplementary CD due to licensing reasons.[1] Since we won't be able to build fonts-chinese-zysong in Koji, we will need to find a way to work around this dependency. It would mean modification to (at least) the Publican spec file, and the pdf.xsl file that ships with Publican.
Configure an Publican-generated website on the webserver
Publican can automatically generate its own website structure on the server. This consists of:
- a configuration file at /etc/publican-website.cfg
- an SQLite database at /var/lib/publican/publican-website.db
- the /var/www/html/docs directory in which Publican publishes documentation
docs.fedoraproject.org would need to point to /var/www/html/docs on the server.
Staging site
Documentation also has a stage at http://docs.stg.fedoraproject.org. This host should also have Publican 2 running on it so that we can stage documents there that are not yet ready for even the "drafts" section of the main docs site. The most important use case would be the nightly builds of translated documentation that the Documentation project produces for the Localization project in the last few weeks before a release. Besides this, however, writers sometimes want to share extremely embryonic documentation. Being able to do this through the automated packaging system keeps even these early stages of development inside the main docs workflow.
Set up a build system for documents
To build documentation packages for docs.fedoraproject.org (and a staging site), members of the docs-writers group need to be able to build packages and place them in a repo accessible by the web servers.
We need to explore:
- could these packages be built for dist-5E-epel-infra? Ideally we would need separate subtags for documents destined for public consumption and those that will only appear on the stage. Members of the docs-writers group would be able to build any docs package and would be able to tag it for the stage; members of the docs-publishers group would additionally be able to tag any docs package for the public site.
- could these packages be built on koji.fedoraproject.org or will we need a separate Koji instance? The biggest issue here is not technical, but procedural, since the current package approval mechanism or packager approval mechanism are not a good fit for the docs project workflow. Since each document package is specific to a particular Fedora release, and since each language is packaged separately, we would have generated 101 new packages for Fedora 13, and needed to grant packager permissions to every member of the Docs team and Localization team working on these packages. It is unlikely that the current review process has the bandwidth to handle this number of new packages every release in a timely fashion; furthermore, since the packages are produced by Publican in a completely automated fashion, it is unlikely that most writers or translators will possess (or will ever possess) the knowledge required to gain packager permissions (but nor do they need this knowledge to build docs packages).
The future
It appears that Publican will ship with Red Hat Enterprise Linux 6, although the version of Publican in the Beta is a late version of Publican 1, which lacks the web publishing components. If Publican 2 ships with Red Hat Enterprise Linux 6, and if docs.fedoraproject.org can be hosted on a server that runs Red Hat Enterprise Linux 6, we will no longer need to maintain Publican and its dependencies in dist-5E-epel-infra.
Also, if Publican 2 ships with Red Hat Enterprise Linux 6, we could build the documentation packages for EPEL as well, assuming that we could get them into Fedora first.
