Re: blends-dev, gsoc 2013
Hi Emmanouil,
On Sun, Jun 09, 2013 at 02:00:24PM +0300, Emmanouil Kiagias wrote:
> I checked the blends' tables in UDD, I played around with some sql
You might always feel free to commit some SQL queries in some playing
area. This makes your tries more transparent and I could make some
remarks.
> and here
> are my thoughts so far, sum up (correct me if anything seems odd or if I
> misunderstood something)
>
> Current blend-gen-control is using the apt-cache dump(provided a source
> list) to fill a list with all the available packages (package pool).
> Then while parsing the task files it keeps track for missing packages
> (using the pool) and creates a structure (perl hash) contaning info about
> the tasks (title, description, depends packages etc). Also for example
> while filling the taskinfo hash the missing "depends" packages for a task
> go to "suggests" etc. Finally using the hash containing the taskinfo you
> can generate the control file and the task description file. Also you can
> print out the missing packages etc.
>
> So we can imitate the above functionality just using info from UDD:
> First we need to get all the available packages (package pool).
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.
> We can do
> that by querying the all_packages udd table (?maybe another table?) using
> the following columns:
Please use not 'all_packages' but 'packages'. The *view* 'all_packages'
assembles other distributions as well what we do not need here (at least
not for the moment).
> "component" and "release" fields (the same arguments a source list is
> using) and most important the "architecture" field (architecture
> dependent).
That's correct.
> Then querying the blends_tasks and blends_dependencies udd tables we can
> get all the taskinfo we need (same as parsing the task files but without
> parsing them) and using the package pool(track missing packages and prepare
> the final taskinfo structure) we can create the control and task
> description files same as before.
Yes, that's the idea.
> Do we need any other UDD tables for the moment?
IMHO that's sufficient for the moment.
> (later we might also use
> the debtags table in combination with the previous tables to get the same
> info ).
Yes.
> The new implementation should also provide methods to parse the
> task files? or will just use blends_dependencies udd table to get the
> needed info(using that there is no need to parse the task files),
Thanks to #703402 I just wrote an importer for the tasks files - so
assumed the gatherer for this information works correctly you can forget
parsing the tasks file. Sorry if one part of the task that was planed
for GSoC is just done before you really start - I promise we will find
some other interesting stuff to do for you. ;-)
> we can
> have both, it depends on how you are planning the maintain the tasks' info
> from now on.
The plan is to keep on maintaining the tasks in VCS (SVN or Git). There
is a daily cron job (there might be good reasons to change the daily
import scheme - but for now it is sufficient) that injects the
information into UDD. We need to make sure that at package build time
VCS and UDD are in sync. I consider reading the tasks files only once
a big simplification (and thanks to Paul #703402 I had this idea).
> These are my thoughts up to now, I will now spend some time on
> the debtags and how to use them and start thinking of way for a changelog
> entry that lists added and removed packages per task (between releases)
> as you requested.
Good. Thanks for your report.
Hope my hints were helpful - just keep on asking if not.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: