Hi,
I have written the pseudo code for blendstasktools.py to use UDD. I have also started rewriting the actual code for blendstasktools.py. Should I keep committing/pushing this partially written code to the repo ? Or is it better to complete rewriting the entire module and then commit the new file ?
On Fri, May 29, 2015 at 4:51 PM, Andreas Tille <
andreas@an3as.eu> wrote:
>
> 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).
I have kept this in mind and am using the ReadConfig() directly for reading the <blend-name>.conf files.
> > 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.
So, FetchTaskFiles() will not be needed anymore. This function basically checkouts svn or git repo, creating a tasks or debian folder and storing all the checked out files here. This function then returns the path to the tasks directory. Since, we have to use UDD, we will not need to check out using svn or git. Am I right ?
> 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)
Noted.
> 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.
So this means we will not be needing SetPublications() in class DependantPackage anymore.
> > 4. class DependantPackage holds information about a package that is in
> > dependency list. In UDD, the table blends_prospectivepackages holds this
> > information.
>
> 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.
GetTaskDependencies() in class TaskDependency reads the tasks files and is parsed using deb822.Sources.iter_paragraphs(). Since, we donot have these task files anymore, as you already mentioned we will need to use the tables packages, new_packages and blends_prospectivepackages from UDD to obtain the data.
I have a couple of questions:
1. We are not checking out from svn or git anymore. All the information present in the tasks files in tasks folder is also availbale in UDD. But what about the debian folder that is created ?
2. One of the files in debian folder is control.stub which is used in blend-get-names to obtain prefix of a metapackage in a blend. Wyy do we need blend-get-names to get the prefix? Can't we just use something like "prefix = blendname.split('-')[1] + '-' " as the prefix for :
i) debian-science -> science-
ii) debian-junior -> junior-
iii) debian-ezgo -> ezgo-
--
Regards,
Akshita