> 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 >
Hello, 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 file. 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: http://bazaar.launchpad.net/~apt-portal-devs/apt-portal/devel/files/head%3A/common/models/ 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 profile. 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 . Thanks -- João LuÃs Marques Pinto GetDeb Team Leader http://www.getdeb.net http://blog.getdeb.net _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community