Hello Andreas, I checked the blends' tables in UDD, I played around with some sql 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). We can do that by querying the all_packages udd table (?maybe another table?) using the following columns: "component" and "release" fields (the same arguments a source list is using) and most important the "architecture" field (architecture dependent). 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. Do we need any other UDD tables for the moment? (later we might also use the debtags table in combination with the previous tables to get the same info ). 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), we can have both, it depends on how you are planning the maintain the tasks' info from now on. 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. Kind regards Emmanouil Kiagias
