Re: [GSoC] Rewriting tasks.py to exclusively use UDD
Hi Akshita,
On Fri, May 29, 2015 at 08:29:38AM +0530, Akshita Jha wrote:
> In blendstasktools.py:
>
> 1. class Tasks uses function ReadConfig() to get all the metadata of a
> blend. In UDD, blends_metadata table contains all the metadata that can be
> extracted through ReadConfig(). So, instead of reading the
> webconf/<blend-name>.conf file, we need to get the metadata information
> from this table.
Yes, this can be done (while the direct use of the config files in the
tasks pages creation would not really harm since it is in the same Git -
I was mainly concerned about the other Blends data).
> 2. FetchTasksFiles() fetches files from SVN of a blend. In UDD, the
SVN *or* Git to be precise, but yes.
> information about the tasks of a blend is available in blends_tasks. I
> think we will need to checkout from git/svn anyway. But we can get all
> other information, about these tasks, from this table.
There is a UDD gatherer that fetches the data from Git/SVN and moves the
(largest part of) the data into UDD. For a start we should use the data
available in this table, yes.
There are some extra data not yet imported into UDD which is:
1. prospective package data - here we should enhance the UDD gatherer
to take this over as well (but this has no priority in the first
stage)
2. publication data - I have sent several warnings that specifying
publication data in the tasks files is deprecated and should be done
in debian/upstream/metadata of the packages in question. My opinion
is that we should rather *delete* these data from tasks files than
fiddling around with it. The publication data belong to a *package*
and not to a task and we should not help people undermining this
principle.
> 3. class TaskDependencies gets the list of dependencies in one metapackage.
> This also uses ReadConfig(). So this will also change to use
> blends_metadata table of UDD.
>
> 4. class DependantPackage holds information about a package that is in
> dependency list. In UDD, the table blends_prospectivepackages holds this
> information. This function needs to be changed so that it gets all the
> information from blends_prospectivepackages.
Not only in blends_prospective packages but also in the packages and
new_packages. All tables have basically the same structure and contain
different "types" of dependencies: Those who can be resolved inside
Debian (=in packages ... the "green" section on the tasks pages), those
that will be resolved soon (=new_packages ... the yellow section below
the green one) and the blends_prospectivepackages which are only in VCS
(also in yellow). The "red" section on the tasks pages is currently not
in UDD and it is IMHO fine to ignore these for the moment. They can be
put into another structural equivalent table later.
> So, in short tasks.py, blendstasktools.py and dependant modules need to be
> modified to largely use blends_dependencies,
> blends_dependencies_alternatives, blends_dependencies_priorities,
> blends_metadata, blends_prospectivepackages and blends_tasks tables from
> UDD.
>
> Am I on the right track ?
Yes, you are.
> I am really sorry for the delay though. I promise
> to cover it up.
I'm sure your exams had some preference over this project, right. ;-)
> Thanking You,
You are welcome
Andreas.
--
http://fam-tille.de
Reply to: