[maemo-developers] Pushing optified Python libs

[From: Dave Neary]

Hi,

Niels Breet wrote:
> User _applications_ should be in user/* categories. (Basically everything
> you want the end-user to see and be able to uninstall) Everything else
> should never be in user.

Where should it go? The packaging policy[1] only explicitly mentions
user/* sections, as does the wiki [2]. As best I can tell we should be
using Debian policy for everything that doesn't appear in the
application manager.

Here's section 2.2 of the packaging policy [1]:

2.2 Sections

Packages are grouped into sections as in Debian, but SHOULD NOT specify
a category in the segment part. (However it is not a bug if a package
taken from Debian and made available in maemo retains its “contrib” or
“non-free” segment.)

Instead maemo defines a user segment for controlling visibility in the
Application Manager. Packages that are intended to be visible in the
Application Manager MUST belong to the user segment, and packages that
are not intended to be visible (such as libraries and other
dependencies) MUST NOT belong to that segment.

[snip]

Packages not in the user segment SHOULD use the sections listed in the
Debian Policy
(http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections).


Looking at that page:

The Debian archive maintainers provide the authoritative list of
sections. At present, they are: admin, cli-mono, comm, database, devel,
debug, doc, editors, electronics, embedded, fonts, games, gnome,
graphics, gnu-r, gnustep, hamradio, haskell, httpd, interpreters, java,
kde, kernel, libs, libdevel, lisp, localization, mail, math, misc, net,
news, ocaml, oldlibs, otherosfs, perl, php, python, ruby, science,
shells, sound, tex, text, utils, vcs, video, web, x11, xfce, zope.

So "python" looks like a promising section.

And I found this document that looks useful for Python packagers, but
doesn't mention sections at all:
http://www.debian.org/doc/packaging-manuals/python-policy/

Is there a list of the standard Python sections & sub-sections somewhere?

> The easiest way to update the python libraries for now is to either
> promote an application depending (>= the new version) or ping me to
> manually push them through.

A library maintainer currently has no way to vote for/test a library &
have it get promoted by the normal QA process? I can imagine, for
example, a situation where a library gets updated, fixing a lot of bugs,
but the application depending on it doesn't bump the depends version. In
that case, what should the maintainer do? Ping you to have it promoted?

Cheers,
Dave.

[1] http://maemo.org/forrest-images/pdf/maemo-policy.pdf
[2] http://wiki.maemo.org/Maemo_packaging

-- 
maemo.org docsmaster
Email: dneary at maemo.org
Jabber: bolsh at jabber.org