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

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"


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:


#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
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


Reply to: