pkgme-devs team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

On Wed, 10 Nov 2010 10:18:38 -0500, Michael Terry <michael.terry@xxxxxxxxxxxxx> wrote:
> OK, but let's take the example of a fictitious C backend.  For 80%* of
> simple apps, the convention is src/.  For others, more complicated
> things happen.  I can't remember the scope for pkgme, but is targeting
> 80% of simple apps enough, or should a C backend look all over?

Let's start with 80% of simple apps. I would like to work with as many
as possible.

> I guess I'm asking if pkgme backends are encouraged/allowed to set a
> convention or work with all setups.  I suspect the answer is that we
> should try to work with all setups.
> 
> * totally made up number

Remember though the role of pkgme, it's just to find the metadata,
things like the project name, the dependencies, etc. For a C backend
this would normally be found by looking in configure.ac or similar.

It's the role of the debhelper buildsystem to actually build and install
the project. I don't think scheme has a debhelper buildsystem yet, so if
we wanted a scheme backend we would have to write that too. That may
require looking for the source files, but usually there will be a
buildsystem to take care of that.

There may be cases where you have to search for the files (scanning for
import statements if the language doesn't have a way to declare
dependencies say). In those cases you may have to look everywhere for
source, but they should be rare.

Usually there will be a build system (distutils, autotools, cmake,
maven, ant, etc.), which has a file or three that you can read to get
the information for pkgme, and an associated command that the debhelper
buildsystem can run to build and install the project.

That's the model I have been working on. If there are cases that don't
fit this nicely I'm keen to look at details, but my bet is that the
majority of project types map somewhat on to this model.

Remember that we are first trying to serve the project authors
themselves, so they could switch to a standard buildsystem if they
wanted. We aren't trying to automate a linux distribution in full, that
has to cope with whatever upstream has decided to do.

Thanks,

James