[ALL] New showroom for Openmoko apps

Joao Pinto joao.pinto at getdeb.net
Tue Aug 25 00:56:19 CEST 2009

> But as RHK pointed out in the next email, someone should test apt-portal,
> because that was talked about earlier and it already exists and should
> be good enough and I've exchanged words with Joao Pinto about it..
> ... Which makes me at least one prime candidate to test it, but today was
> a horrible Monday.
> David Martinez of Tuxbrain dabbled in it, wonder if anything came out of it?
> I'll give it a shot tomorrow.
> --
> mjt

I don't have a diagram for the APT-Portal database model, actually I
find more important the the rational used on it.
When I have developed the database design for www.getdeb.net 3 years
ago, I had a great focus on data, on it's representation as entities
(tables) and relations. It has been usable, however I have found
myself building complex queries and code to achieve simple goals. This
time I have followed the opposite direction and so far I am happy with
the results.

On my perspective there are 3 key groups of information that you need
for a software portal:

Back-End - Repository/Archive
This describes the organization of the software components and it's
relations on the archive, on my case there was nothing special to
define, APT has already a clear structure, there is a URL which points
to a repository , the repository is described by a "Release" file and
the contents of that repository/component is described at a Packages
Because such repository is already defined as part of the distribution
system, I have just developed a script which imports data from a
generic APT repository to the database, the data on the repository
tables is populated from the "upstream" repository - there was an
exception introduced later, a package can either provide : m - main
package (provides an application). o - optional package (provides an
optional package for an application, like -server for a game) and i -
inter package (for data libraries etc), such classification is
directly related to packages and is not present on the repository,
this is the single human inpurt field introduced on this group.

Front-End - Application/Application Category
This provides the core information about an application, like
description, name, homage, description translations, screenshots,
youtube demos, etc.
There is no enforced reference (foreign key) to the repository group,
however there is a "source_package" field which identifies a source
package that (if available) provides the main and optional packages
for the application.

Management - Who can do what
This provides the user and groups information, groups provide
privileges to manage both the repository and applications, so far we
are using a single group "admin" which can both defined/edit
application entries and issue repository management commands (remove,
copy from testing to stable)

If you want to check the current tables definition just browse:

Now talking about security, because that is specially key requirement
for any public site.
General - apt-portal can easily be run using an appamor profile,
generic traversal, file retrieval/creation could be possible with code
exploits but are limited according to the strictness of the appamor
SQL Injection - we are using SQLAlchemy and bind parameters, sql
injection is not possible
XSS Exploit - can be prevented by using Mako's templating engine
built-in html or url  filtering on dynamic parts on the templates

Please give a try to APT-Portal, I do not know if it can cover your
requirements, if it does it would be a great collaboration
opportunity, working on the back-end requires specific knowledge on
repository the technology used, bout the front-end and management
could easily be shared across different projects.

If you have an Ubuntu LiveCD around just test-drive
http://www.playdeb.net/, it's built on top of APT-Portal .


João Luís Marques Pinto
GetDeb Team Leader

More information about the community mailing list