[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#703402: PTS: link to the blends website for packages involved in blends

On Wed, Mar 20, 2013 at 04:28:14PM +0800, Paul Wise wrote:
> [Please keep the bug in CC]

Yep.  I noticed my mistake in last mail and bounced it right after
sending to the bug
> On Wed, Mar 20, 2013 at 12:55 AM, Andreas Tille wrote:
> > If it comes to Blends topic I am an UDD folk. ;-)
> > You should simply specify what data you need and I will go for it.
> So, a machine readable file (YAML/JSON/deb822/etc, your choice),
> something like this:
> Blend: Debian Med
> Task: Biology
> Task-name: med-bio
> URL: http://debian-med.alioth.debian.org/tasks/bio
> Packages: abacas acedb-other ....
> Blend: Debian Med
> Task: Biology development
> Task-name: med-bio-dev
> URL: http://debian-med.alioth.debian.org/tasks/bio-dev
> Packages: bioperl bioperl-run

Well, machine readable file is one thing.  At first we need to define
the SQL table layout.  Currently the philosophy in UDD is to have the
tables not normalised but I think it makes sense to normalise to some
extend into three tables because it simplifies things we intend to do:

  CREATE TABLE blends_metadata (
  -- fieldname   type,   --  example value
     blend       TEXT,   --  'debian-med'   (== the source package name)
     blendname   TEXT,   --  'Debian Med'   (== human readable name)
     projecturl  TEXT,   --  'http://debian-med.alioth.debian.org/'
     tasksprefix TEXT,   --  'med'
     PRIMARY KEY (blend)

  CREATE TABLE blends_tasks (
  -- fieldname   type,   --  example value
     blend       TEXT REFERENCES blends_metadata,
     task        TEXT,   --  'bio'
     PRIMARY KEY (blend, task)

  CREATE TABLE blends_packages (
  -- fieldname  type,   --  example_value
     blend      TEXT REFERENCES blends_metadata,
     task       TEXT REFERENCES blends_tasks,
     package    TEXT,   --  'gromacs'
     PRIMARY KEY (blend, task, package)

These tables could be filled from configuration files in


in dir webtools/webconf as well as from tasks files in SVN.  When
thinking twice it might be worth considering to drop the webconf stuff
in favour of putting the information in question right into the source
package metainformation.  But this could be decided / adapted later.

>From the table layout above it is a simple task to create YAML,JSON
which I consider rather *your* choice - I even wonder if there is any
need for an intermediate format.  Isn't PTS not created from UDD

> > I'm sorry I can not really parse what you want to tell me with this.
> I'll try again. The PTS is primarily source package based but the
> blends infrastructure is binary package based. The PTS will want to
> link to the blends infrastructure, using per-package anchors. The
> anchors provided by the blends infrastructure are based on binary
> package names rather than source package names. Here is an example
> based on the logol source package:
> <a href="http://debian-med.alioth.debian.org/tasks/bio#logol-bin";
> title="Debian Med Biology packages">med-bio</a>
> <a href="http://blends.alioth.debian.org/";>blend</a>
> It would be much better if the PTS could link directly to a source
> package anchor instead, especially since blends can sometimes depend
> on multiple binary packages from one source package. Unfortunately it
> isn't yet possible to do this:
> <a href="http://debian-med.alioth.debian.org/tasks/bio#logol";
> title="Debian Med Biology packages">med-bio</a>
> <a href="http://blends.alioth.debian.org/";>blend</a>

Ahhh, OK.  Adding an additional anchor mentioning the source should be
no problem in principle (at least not when the planed changes will be
implemented - I'll issue a GSoC proposal about this).  However, there is
always a number of binary packages from one single source package inside
a single task - this would result in duplicated source package anchors
which IMHO is not a really good idea (I guess browsers are defaulting to
the first anchor - but finally something is happening you really want to
prevent).  So this approach is a bit hackish because there is a reason
why tasks are binary package centric (== user oriented) and PTS is
source centric (== developer oriented).  I guess this mix of target
groups leads to the technical problem we are facing.

> Alternatively we can drop the anchor, since I guess folks clicking on
> blends links are looking for other related packages rather than the
> package itself.

IMHO this would be the better solution because it resolves the conflict

> Thats a separate issue to what you pointed out with gromacs, the
> gromacs issue can be solved like this:
> <a href="http://blends.alioth.debian.org/debichem/tasks/molmech#gromacs";
> title="DebiChem Molecular mechanics packages">debichem-molmech</a>,
> <a href="http://debian-med.alioth.debian.org/tasks/bio#gromacs";
> title="Debian Med Biology packages">med-bio</a>
> <a href="http://blends.alioth.debian.org/";>blends</a>
> And if the length of the blends list gets too long we can do it like this:
> <a href="http://blends.alioth.debian.org/";>blends</a>
> (<a href="http://blends.alioth.debian.org/debichem/tasks/molmech#gromacs";
> title="DebiChem Molecular mechanics packages">1</a>,
> <a href="http://debian-med.alioth.debian.org/tasks/bio#gromacs";
> title="Debian Med Biology packages">2</a>,
> <a href="http://debian-med.alioth.debian.org/tasks/cloud#gromacs";
> title="Debian Med Cloud packages">3</a>)

OK, that's fine for me.  I will not question PTS development decisions.
In any case I'd applause the intention to make Blends more visible. 

Kind regards



Reply to: