Hello Andreas,
On Tue, Jul 30, 2013 at 1:01 PM, Andreas Tille <[email protected]> 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
