Re: blends-dev, gsoc 2013

Hello Andreas

On Sun, Jun 9, 2013 at 9:23 PM, Andreas Tille <andreas@an3as.eu> wrote:

I would turn around what you are doing "first": It's easier to look
up into my "SQL playing area"

anonscm.debian.org/gitweb/?p=blends/website.git;a=tree;f=misc/sql

you see gis-thermometer.sh (to be announced soon) which *first* looks
into table blends_dependencies and later joins table packages restricted
to certain releases - the testing release is your friend.

My first approach is the following script:

#!/bin/bash

#parameters: (1)blend_name (2)release_role (3)architecture

#example of usage ./script_name debian-med testing amd64

psql udd << EOT

SELECT b.blend, b.task, b.package, b.dependency, pkg.architecture

FROM blends_dependencies b LEFT OUTER JOIN (

SELECT p.package, architecture

FROM packages p JOIN releases r ON p.release = r.release

WHERE r.role='$2' and architecture='$3' ) pkg ON b.package = pkg.package

WHERE b.blend='$1'

ORDER BY b.task

EOT

As you said first I get all the blends_dependencies for a blend and I join a table restricted to a certain release and a certain architecture. With the output of the above script we have all the dependencies for a blend and also we have the missing packages for an architecture. This is my first sql approach to get the info we need for the control file.

Also I thought about a way for achieving some kind of changelog entry creation

between the latest release and the current release of a blend that lists added
and removed packages per task. From a previous older discussion we had you gave me the following example of entry log(in this example we use Debian med blend):

----------------------------------------------------------------
debian-med (1.14) unstable; urgency=low

* Changes in metapackage dependencies
- med-bio:
added: package_a, package_b, ...
removed (optional): ...
- med-...
* New metapackages
- med-...

My one question here is how you define a release? I suppose you use VCs tags. If that's true then we can do it the following way:

*For blends that are maintained in svn:

We can get the revision numbers of all the existing tags. Then having the revisions we can use them with svn diff /path/to/blends/task/file -r revision1:revision2 , parse the diff output and keep the added and removed packages per task per blend etc.

*For blends that are maintained in git:

The idea is the same with the svn, git is quite handy with the tags and we can use them with git diff to track the added/removed packages in a task between tags releases.

Apart from the tags we can use straight svn commit revision number(or commit hash in git) for the latest and a/the previous release to get the differences. So this method can be called (eg can be called as a svn/git hook maybe?) every time you tag/commit a new release for a blend. Anyway the changelog entry is indepedent from the main goal of the project so we can come back to it anytime.

I am looking forward to start coding for the project :-) . Any other ideas, feedback or features are more than welcome.

Have a nice weekend.

Kind regards

Emmanouil