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

Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)



Hello Andreas,


On Tue, Jul 30, 2013 at 1:01 PM, Andreas Tille <andreas@an3as.eu> wrote:

The patch needed some additions to the importer (sure, if we prevent
something by a constraint we need to make sure the data breaking the
constraint will not be included).  So while we now have a clean database
I'm a bit concerned about the way how we avoid the duplicates.  Strictly
speaking it is the fault of the metapackage designer but IMHO we should
try to be error tolerant.  What might happen is that we get some sequence
inside the tasks file say

Ignore: foo

Depends: foo

Suggests: bar

Depends: bar

In the database we would get

udd=# SELECT package, dependency FROM blends_dependencies WHERE package in ('foo', 'bar') ;
 package | dependency
---------+------------
 foo     | i
 bar     | s

even if both should get a dependency 'd'.  Currently I issue error lines into
the logfile.  Just check

   grep -iw error blends_metadata_gatherer.log

However, it seems to be clear that this logfile is rarely visited and so
I wonder what to do.  Should we check for the strongest possible
dependency?  Should we just accept what comes first (as we do now).
 
I got your point, you are right, when that happens it is a problem. To be honest I am not quite sure what is more *correct* in this case. Maybe storing the strongest possible dependency seems better but if a package appears in Depends and Suggests(or other cases) then there is no hint what is *better* cause basically is an error in the task files. 
  
Currently those cases are only in debian-edu and I will talk to the
debian-edu people at DebConf anyway, but I wanted to mention this
problem here. 
Yeap that will be helpful, also thanks for mentioning because I did not think of that yesterday when we had the talk about the duplicates.
 
Perhaps we include an example of the problem below into Debian Fun task
to make sure we will not forget.

I will add them.
 
Once I was using the database including constraint the resulting taskdesc
files were OK.

:-)

 Also I just made a commit where I added Makefile and rules files in the project. For the moment I commented out the packages.txt/avoidpackages.txt from Makefile. I tried running "make dist" inside a blend and it seems to work(orig.tar.gz file is generated containing the needed control/taskdesc files). I generate a control file and a taskdesc.template. In the rules, for testing, I generate a taskdesc.<arch> from the template using the host's arch. This also seems to work. For local testing I have added custom local path into the Makefile/rules. Except from  Makefile/rules file what else we need at this moment?

 
Kind regards

Emmanouil

Reply to: