[maemo-developers] Pushing optified Python libs

[From: Niels Breet]

On Fri, December 18, 2009 15:28, Dave Neary wrote:
> 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.
>

Yes, python is ok. As long as real end users don't see it in the
Application Manager.

Developers have python available in SDK and also know how to handle either
red-pill or apt-get.

>
>> 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?
>

We've discussed this at the summit and came to the conclusion that we
basically need library maintainers. Another conclusion was that we needed
to discuss that further :)

Until we have the repository/library maintainer track sorted out, I
propose to follow these steps:

- If you are not listed as maintainer for an existing library and still
want to have it updated, contact the maintainer. If the maintainer is not
available or doesn't respond, mail to maemo-developers list.
*** Please don't update a library maintained by anybody else without
consent or public discussion***
- The maintainer/author uploads new version, checks if applications using
the app still work correctly.
- Ping me or mail -developers to push it through manually to testing. Here
we can all do a final test to see if nothing breaks.

I hope to have an interface for maintainers available in the beginning of
the new year.

This doesn't solve the problem that the Application manager doesn't update
libraries on their own though. That problem should be a separate
discussion.

> 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
>

--
Niels Breet
maemo.org webmaster