Hello Andreas
On Sun, Jun 9, 2013 at 9:23 PM, Andreas Tille <[email protected]> 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
