On Tue, 2013-03-19 at 10:47 +0100, Andreas Tille wrote: > On Tue, Mar 19, 2013 at 04:33:41PM +0800, Paul Wise wrote: > > <a href="...">jr</a>, <a href="...">games</a> <a href="...">blends</a> > > For the moment I see some problem here because a single package could > perfectly be part of more than one Blend as well as part of more than > one task of a single blend. For instance consider gnuplot in Debian > Science: Right, hence the links to multiple blends in the example I gave. > So putting a binary package into a task is not a strict (=exclusive) > categorisation because one binary package could serve several different > purposes. I have no idea whether this can be reasonably reflected in > PTS. I think it can, with multiple links. > This can be approached and I could perfectly imagine to put the content > of all tasks files into an UDD table if this might simplify things. But > also here we should choose the table design apropriately: You can either > give the Blend / Task preference like The PTS converts data in various into XML files for rendering using XSLT, but importing via a UDD CGI sounds fine, we would need the UDD folks to add that script though. > They are: > > http://debian-med.alioth.debian.org/tasks/bio#gromacs > > to stick to the later example of gromacs in Debian Med. Here is a more problematic example, #logol doesn't exist but #logol-bin does. It might be possible to do the second link, the first is easier. http://debian-med.alioth.debian.org/tasks/bio#logol http://debian-med.alioth.debian.org/tasks/bio#logol-bin -- bye, pabs http://wiki.debian.org/PaulWise
Attachment:
signature.asc
Description: This is a digitally signed message part