Re: blends-dev, gsoc 2013
Hi Emmanouil,
On Sat, Jun 15, 2013 at 06:56:54PM +0300, Emmanouil Kiagias wrote:
> 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.
Looks good. I tried the script and noticed it is the same as you commited to
git://git.debian.org/git/blends/blends-gsoc.git
So if anybody wants to test it it might make sense to check it out from
there. I noticed that the result does not enable one from
distinguishing the status of the packages properly. You only check for
specific architecture or not. But we do also have
autodocktools -> non-free (and thus should be rendered as Suggests)
wgs-assembler -> not in Debian (also rendered as Suggests)
Moreover you have no real distinction between the fact whether a package
is simply "Architecture: all" or whether it is simply not available for
this architecture. For instance if you look at soapdenovo[1] it is not
available for several architectures - but in your result set this is not
reflected.
If you have no idea how to get this information with a more detailed
query feel free to ask.
> 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.
Yes. Currently we are using tags in SVN. The plan is to move to Git
(even if I do not know whether it is a good idea to force all Blends to
move immediately - so relying onto Git only should be discussed first).
> 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.
As I said we could use VCS but I'm not fully convinced that relying on
diff to get structured information. While we can test it fir sure
whether it works out practical as an alternative approach I would
consider just dumping the status of a release as JSON data right into
the source package. While we will not be able to create changelogs to
previous releases I would consider this a minor flaw because those
changelogs are just written (as bad as they are, thought). We will not
change those changelogs afterwards anyway. So if we create some file,
say <blend-name>.json with every run we could (also relying on VCS tags)
just compare the fresh data with the JSON data from last release. IMHO
this comes more handy than a diff which needs to be parsed carefully
which might come more expensive that just browsing a JSON file.
> 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.
Right. I would delay this a bit.
> I am looking forward to start coding for the project :-) . Any other ideas,
> feedback or features are more than welcome.
Kind regards
Andreas.
[1] http://packages.debian.org/sid/soapdenovo
--
http://fam-tille.de
Reply to: