Re: blends-dev, gsoc 2013
On Sun, Jun 02, 2013 at 05:42:29PM +0300, Emmanouil Kiagias wrote:
> > No questions so far. I personally would start by creating SQL queries
> > (functions if needed) to assemble the needed information. Once this is
> > there it could be wrapped up in a Python script that writes the task
> > file. Keep it simple for the first shot - we will enhance it later.
> > So you mean for the begging write a python script which will generate the
> task files for a blend using information from udd?(sorry for maybe
> repeating the above sentence but I got a little confused)
I rather mean write SQL code and put them into testable scripts into
Git. At least this is my way to test the SQL code either by using files
ending up with *.SQL you could pipe into `psql udd` or you can also use
simple shell scripts. I just created two such examples here:
The first script gis-thermometer.sh tries to reimplement the gathering
of data for the Debian GIS package thermometer that could be
implemented for all Blends in a similar manner. The second script
upgradable.sh tries to find all packages that can be upgraded to newer
upstream per Blend.
Simple scripts like this can be easily tested and verified whether they
deliver the data we need. Once we have the data correct this can be
wrapped up into a Python script that will output the control file in
> The blend_dependencies table contains the package dependencies for the
> blends' latest release?(because I do not see a column containing the
> version of a blend)
It rather contains the status of SVN (trunk). This is what I was caring
for in the first place and this is from what we need to create the
metapackages from (which is equivalent to the creation process currently
which also uses trunk.
> Also in the blend_dependencies table, what do the four possible values (d,
> i, r, s) of the column dependency mean?
In you other mail you confirmed that this became clear to you.