[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: GNOME Policy, draft 0.0.0.1



This is the latest draft.



Debian GNOME Mini-Policy
Copyright (C) 2003, Ross Burton

Version: 20020113-2
Author: Ross Burton <ross@burtonini.com>

Currently this document is simply a list of "best practises" for
packaging GNOME libraries and programs. As it evolves it should become
more organised.

Programs that the end user can actually run (such as File Roller)
should be packaged as the name of the program. Do not suffix the
package with a "2" to represent the GNOME 2 package; if upstream is
maintaining both GNOME 1 and GNOME 2 releases, then name the GNOME 1
package foo-gnome1 instead.

Nautilus views should be packaged as "nautilus-[viewname]". As they
are not executable by the user, they should be installed into
/usr/lib/nautilus. Note that often upstream .server files hard-code
/usr/lib, and this will require editing of the Makefile and .server
files.

Panel applets -- "gnome-applet-foo" or "foo-applet"? If the applet is
a binary, these are not directly executable so should be installed
into /usr/lib/gnome-panel. If the applet is a shared object, also
install it into /usr/lib/gnome-panel, as another program cannot
directly link to it.

GTK+ 1.x engines are named gtk-engines-foo. GTK+ 2.x engines are named
gtk2-engines-foo. Note that unless there are special requirements,
GTK+ themes should not specify a font. How do we package pure gtkrc
themes which use engines (such as GitM, which uses gtk2-engines-mist)?
Should engine packages include a set of decent themes for this engine,
even if they were not written by the same author?

TODO: Icon themes? Metacity themes? Metathemes?

The documentation of a library should be generated with a tool such as
gtk-doc or doxygen at package build time, and either included in the
-dev package if it is reasonably small, or in a separate -doc package.
API docs should be installed in /usr/share/doc/foo-{doc|dev]/,
normally in a folder named after the type of file (such as "html").
All API documentation should include a doc-base and .dhelp file. Also
package the .devhelp file is it exists (gtk-doc will generate one), in
/usr/share/devhelp/specs, with a symlink in /usr/share/devhelp/books
to the API documentation. If the documentation is built with gtk-doc,
it will be installed into /usr/share/gtk-doc/html/foo.  This should be
moved into /usr/share/doc at build time, probably with dh_install.
Many configure scripts support --with-html-doc-dir to relocate the API
docs, but this sets the base name for the files and will be appended
with the package name, so is not as useful.

If user documentation exists, and a .omf file is provided, the package
should depend on scrollkeeper (>= 0.3.8), and register the documentation
in
postinst/unregister in prerm.

postinst:
        scrollkeeper-update -q

postrm:
        if [ "$1" = "remove" ]; then
                scrollkeeper-update -q
        fi

Currently, Debian has no XML catalogue.  This means that when
Scrollkeeper is used to register user documentation, it will try and
connect to the Internet and download a DTD. As a temporary measure,
replace the URL with a absolute path.  For the details of this, see
bug #155129.

An example script to do this would be:

    find -name '*.xml' -exec perl -i -pe
's,http://www.oasis-open.org/docbook/xml/([^/]+)/docbookx.dtd,/usr/share/sgml/docbook/dtd/xml/\1/docbookx.dtd,' {} \;
    find -name '*.omf' -exec perl -i -pe
's,http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd,/usr/share/xml/scrollkeeper/dtds/scrollkeeper-omf.dtd,' {} \;

Run this one-liner before running 'make'.

Many GNOME applications use GConf for preferences, and they should all
provide schemas. These must be installed specially -- before running
"make install", GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 must be
set. This will ensure that the schemas are not installed onto your
local machine in the package build tree. Then, in the postinst script,
register the schemas manually.

postinst:

        if [ "$1" = "configure" ]; then
            SCHEMA_FILES="foo.schemas bar.schemas"
            for SCHEMA in $SCHEMA_FILES; do
                if [ -e /etc/gconf/schemas/$SCHEMA ]; then
                    HOME=/root GCONF_CONFIG_SOURCE=`gconftool-2
--get-default-source` \
                    gconftool-2 \
                    --makefile-install-rule /etc/gconf/schemas/$SCHEMA >
/dev/null
                fi
            done
        fi

Simply change the value of SCHEMA_FILES to list all of the schema
files, in /etc/gconf/schemas.

When gconftool supports it, the prerm script should also un-apply the
schemas when the package is being purged. This is currently
unimplemented in gconftool however.

TODO: I plan to write a dh_gconfschema helper which will auto-generate
the relevant postinst/prerm scripts.

If the binaries accept the standard GTK+/GNOME options, in the manual
pages refer to the GNOME options manual page . TODO: what was the
status with this? Is it packaged anywhere?



Ross
-- 
Ross Burton                                 mail: ross@burtonini.com
                                           jabber: ross@nerdfest.org
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: