On Tue, Aug 25, 2009 at 10:35 PM, Markus Törnqvist<[email protected]> wrote: > Hi! > > Having looked at apt-portal[1] my vote says that should be used for > whatever we're going to build. > > Here are some practical questions: > > 1. Where to read about different distros, or more specifically their > packages? > What are these magical bb recipes, for example, and to what extent > are they relevant to our interests? > > 2. How exactly does apt-portal build links to package installations? Generating installs links depends on the "install from web" tecnhology available on the distro (if any), on the case of Ubuntu the tecnhology is apturl (https://help.ubuntu.com/community/AptURL) . APTURL depends on the repository providing the package being already configured on the user system, for that we provide instructions on our pages. The links are just as simple as apt://package-name , the package_name is determined by searching for the "main" package provided by the "source_package" defined on the application table. > > 3. Where does the distro information live in the apt-portal db? Table packagelist This table is automatically populated based on the info available on the "Release" file retrived from the repository . > > 4. How do different distros update their repositories? > What I'm meaning here is, that are they using something like dput, > for which we could write a hook that publishes the new version in apt-portal > when uploaded to stable?
We have a cronjob which imports the data from the repository at an high rate, every 5 minutes. The import is differential (insert/delete) so there is no major performance impact on the db. > > 5. We will track testing and unstable as distributions too? > Joao, if you see this, how does that testing checkbox in apt-portal work? Testing/unstable are imported as any other distro since on their Release file they have such identification to differentiate them, however the default distro filtering for applications presentation excludes distributions with a codename "*-testing", the checkbox on the distro selection will override this. Please note that the user will also need to have the -testing repository setup to be able to get the "testing" versions. > > 6. Where would we host our stuff? > I think getting bzr access to apt-portal would be real nice for all the > people interested, but is it ok to clutter up apt-portal's bzr with > "irrelevant" application-domain stuff like openmoko, instead of just > tracking the features that benefit everyone. The apt-portal structure has already such distinction, there are two base directories on the source: common/ - It contains common controllers/viewers/db models applications/application - It contains app specific controllers/viewers/db models We have a single application deployed (playdeb) so there are some files which do not meet the expected organization, this will be improved once we provide another application. Right now we have the entire source, apt-portal/* and apt-portal/applications/playdeb on the same bzr branch, because we are still on an early stage of development, most of the times we need to update both sources, on the future we plan to have a bzr for apt-portal/* and another for application/appname . We could grant you access access to apt-portal's bzr, you could maintaine application/your_app_name in whatever version control system you find appropriate. > > 7. Upcoming feature: comment and reviews > Looking at the apt-portal db schema, it makes most sense to have comments > per application, though I am still partially against it ;) > Maybe the comments should be tied to distro and version but displayed > per application... What do you think? I think that comments should be per application and using a tagging system for the version of the package, there is another feature that I want to be available on comments: internationalization, users must have the ability to select between all, english only or local only comments view. > > 8. Upcoming feature: application management > I'm not sure if this is already supported by apt-portal but I guess not. > The idea would be that if someone is the programmer, a part of the programming > team, or the packager, or whatever, he would get access to edit the > application on the site, to not always bother someone else with it ;) This is something easy to implement, it needs a new user group "editor", and a controller allowing to list/selecting the application. The app editing itself is already implemented at /app, so it is just a matter of linking to it with the proper parameters. > > If all that ties together, basically "just running" the upstream repository > with some post-publish hooks might maybe make this showroom of ours run > itself.. > > (Of course it would be cool to have our own mirrors and distro management > framework etc in the future but that's not relevant to this, at least not > this milestone 1 ;) > > What do you distro maintainers think? apt-portal maintainers? community? > > Thanks! > > [1] > https://launchpad.net/apt-portal > http://wiki.getdeb.net/apt-portal/Download > > -- > mjt > > > _______________________________________________ > Openmoko community mailing list > [email protected] > http://lists.openmoko.org/mailman/listinfo/community > -- João Luís Marques Pinto GetDeb Team Leader http://www.getdeb.net http://blog.getdeb.net _______________________________________________ Openmoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
