[ALL] Showroom practices

Joao Pinto joao.pinto at getdeb.net
Wed Aug 26 13:21:28 CEST 2009


On Tue, Aug 25, 2009 at 10:35 PM, Markus Törnqvist<mjt at nysv.org> 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
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>



-- 
João Luís Marques Pinto
GetDeb Team Leader
http://www.getdeb.net
http://blog.getdeb.net



More information about the community mailing list