pkgme-devs team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

Hi,

pkgme trunk is almost ready to make use of backends, and the interface
is there such that you could write to it now if you wanted.

I talked to Barry today about generating documentation for backend
authors, which we want to do before publicising too widely, so that we
can get as many on board as possible. I hope you are willing to wing it
a bit though, and so here's a summary of what a backend needs to
provide:

A backend in a directory, named after the name of your backend (python,
gnome, vala, java, ruby, whatever), containing some scripts that are run
by pkgme to get the information that is needed.

All scripts are run with the current working directory being the project
that is being packaged, so they should get the information from there.

The first script is called "want", and is used to determine if your
backend wants to deal with this project. This script should return an
integer implying how much it knows about the project. This is done so
that you can have more specific backend if you want. For instance there
may be an autoconf backend that can cope with the standard configure;
make; make install; project, and then a GNOME backend that knows about
the conventions that GNOME adds to this. In that case the GNOME backend
can return a higher score if it finds the GNOME layout.

What score should you return? This is obviously relative, but as a
guideline, I would suggest that you start by returning:

  10 - if you barely know much about the project
  20 - if you are a backend that knows how to deal with a basic language
  project and this is for your language (generic python, java
  etc. projects)
  30 - if you have some specialised knowledge about the project

with higher numbers and those in between for us to adjust as we add more
backends.

Next you get a choice of how to deal with providing the information. The
simple way is to name a script after each of the values detailed below
that you can provide. For instance, to provide the package name, provide
a script named "package_name" which prints the package name when called.

If this isn't satisfactory, either because you want to make use of
shared code between all of the scripts, or because providing the
information is expensive for some reason, you can provide a single
script to provide all of the inforamtion about the package (except the
"want" score).

If you want to do this then provide a script called "all_info". When
this script is called stdin will be fed with a JSON-serialised list of
the information that is wanted (see below for what the values can be).
All of the information that is known should be determined, and then
written on standard out as a JSON-serialised dict. For instance, if the
package name and build dependencies are wanted then the script will
receive

  ["package_name", "build_depends"]

on stdin, and should respond with something like

  {"package_name": "foo",
   "build_depends": "bar"}

If a piece of information isn't known then either omit the key from the
output dict, or return null as the value for that key.

pkgme will use this interface to get all of the information that it
needs and to write out the packaging. It currently doesn't write very
good packaging, and more information will be requested later, but for
now the information requested is:

  * Required:
    - package_name: the name of the package (source and binary)
    - maintainer: the maintainer of the package (name and email address)
      - this probably shouldn't be required, with a sensible default
        applied.
    - architecture: the "Architecture" for the binary package (any, all,
      a list of one or more architectures, or something more
      complicated, usually just one of the first two)
    - description: the description of the package, preferably formatted
      as the Debian policy expects.

  * Optional:
    - buildsystem: the dh 7 buildsystem to use. Useful to ensure that
      dh doesn't detect another build system.
    - section: the section to put the source and binary in to. Defaults
      to "misc", but you may be able to hint at another.
    - homepage: the website of the project.
    - build_depends: the build dependencies of the package.
    - depends: the dependencies of the binary package.

I would suggest that you don't try and be too conservative with the last
two.

Please let me know of anything that is missing for you to be able to
write your backend, or if this scheme doesn't work for you.

There are still some un-answered questions that we will have to deal
with, such as user-supplied information, and persisting information
between runs, but I think this is a good base to work from.

Thanks,

James