anderson.lizardo at openbossa
Nov 6, 2009, 5:18 AM
Post #1 of 4
(521 views)
Permalink
|
|
extras vs. extras-devel: how to handle new bindings and developer packages in Fremantle?
|
|
Hi,
As some of you might know, the PyMaemo team maintains various bindings
and development tools for Python that are used to develop user
applications. I mean, core Python packages such as pygtk,
python-hildon and python-hildondesktop. Therefore it can be said the
we provide a "Python SDK for Maemo".
Until Diablo, we followed the policy to promote all PyMaemo packages
(even developer tools) to extras, and ask developers to add the
"extras" repository to the scratchbox target's /etc/apt/sources.list,
as a prerequisite for Python development on Maemo.
This worked nicely because we had the freedom to upload any kind of
package (user level or not) to extras. Of course, they did not appear
on the tablet's application manager because they were not in the
user/* sections.
But for Fremantle this is not the case anymore, due to the new QA
process (which I personally like, although it needs some more
polishing, already being discussed on the list). The QA seems to be
very GUI/user centered, from what I can read from the instructions on
the wiki.
So how should we handle developer tools in Fremantle? I see some options:
A) keep packages in extras-devel and instruct developers to add
"extras-devel" repository to their sources.list (in the scratchbox
targets)
B) Let dev tools go through extras, maybe into a special non-user
section (so they don't appear on the application manager). Then
instruct developers to add the "extras" repository to scratchbox
instead.
C) create a separate repository for developer tools, just like there
is the official SDK tools repository. The instruct the developer to
add this new repository into their sources.list (or even better, have
it already enabled by default in the SDK rootstraps).
On a related issue, It seems unclear to me where to upload things like
new Python bindings to be used by developers. So far the "auto
promotion of dependencies" approach has worked for *existing* bindings
(such as pygtk, python-hildon), but what about the new bindings that
have not yet been used by any application (and thus are only in
extras-devel)?
To illustrate the problem, I list below the PyMaemo packages which are
not yet in extras-testing/extras, due to the reasons explained above.
These packages provide Python bindings/extensions not yet used by any
user applications in fremantle extras-testing queue nor extras,
therefore were not "auto promoted":
pybluez - Python bindings for BlueZ (bluetooth stack)
pyopenssl - Python bindings for OpenSSL
python-conic - Python bindings for Internet Connectivity library
python-mafw - Python bindings for MAFW
storm - Database access module for Python
The main problem with above packages is: how will the developer begin
using them if they are not on extras?
These packages are developer tools, used only on Build-Depends, and
therefore will never be auto promoted:
cython
pyrex
python-setuptools
python-runtime (metapackage which pulls some more popular PyMaemo
components for quick & easy development start)
Ideas?
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
_______________________________________________
maemo-developers mailing list
maemo-developers [at] maemo
https://lists.maemo.org/mailman/listinfo/maemo-developers
|
