Hello Andreas On Thu, Jun 27, 2013 at 10:51 AM, Andreas Tille <[email protected]> wrote:
> > > > ./blend-gen-control -b debian-med -c -D -S (so you have -c for > gen_control > > -D for nodepends, -S suppressempty) > > Ahhh - sure. This is what we agreed upon. I'd call it a useful feature > if either -c or -t would be a required option. Otherwise it is > confusing if the script needs some time ... to do nothing. > Ok I fixed this (so now either -c or -t are required or the script will dump an error message) > > or for generating the task descriptions files you can do: > > > > ./blend-gen-control -b debian-med -t -S (-t for task_desc) > > Seems the Key value is always med. It should be like > > Relevance: 10 > Key: > med-bio > Packages: list > ... > > Relevance: 10 > Key: > med-bio > Packages: list > ... > > > But in the new output it is always only 'med' > > Yes you right, I forgot to do the right "format" in python,I fixed it, I think now it should be ok. Note: I have made a git commit yet so the fixes are not there Nonetheless - the more I'm thinking about we should discuss with other > Blends whether it makes sense to support an optional Section field > inside the tasks files which could be used to override the default of > "Section: misc". > > > > I think we need to make sure that *every* information will propagate > > > into UDD. If you are interested you can perfectly try to dive into > > > this. It is > > > > > > git://git.debian.org/git/collab-qa/udd.git > > > > > > and you need to redefine the table columns (see dir sql/) and adapt > > > udd/blends_metadata_gatherer.py to read in the data. > > > > > Yes I am interested, I will check that :-). > > Feel free to send me patches in case you are unsure about changes to UDD. > > Ok for the moment I will provide fixed values: Priority : extra Section : misc Most of the Blends do not provide a Section field(optional as you said) so we can leave it empty for those it but in cases they provide it (like some task in education blend) ,as you said, we can override the default(or the null value) and add it to the generated files. Also I forgot to mention that yesterday: I think we also need to save the "Leaf" field for the tasks, because in the task description file we do not print out the tasks which have the Leaf : false. For example the education blend tasks : chemistry, common, electronics etc have a field Leaf : false and thus they are not included in the task-description file. Without this field my code can not disguise the non leaf tasks so for the moment it dumps everything(which I do not think its correct). Also the same goes for the field/header : Test-always-lang(as we discussed in the previous mail). And as you said | I think we need to make sure that *every* information will propagate into UDD Yes I also agree. A first quick(and little dirty) solution it can be to add these extra fields (Leaf etc) in the blends_tasks and for those tasks which do not provide them can be left NULL in the UDD. The problem with this solution is that these extra fields( mandatory if they exist) are not represented by the majority of the Blends(most of their tasks do not include them). So another better solution (a quick idea) can be the following: In order not to spoil the blends_tasks UDD table(its fields are fine cause all blends' task provide these info) we can have an extra table for example with the blends_tasks_extra(or whatever sounds better) with the following fields: table: blends_tasks_extra : - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Task(primary key) | field(or header) | value - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - lang-de | Test-always-lang | de chemistry | Leaf | false ..... That way we can get from UDD any extra fields a task might contain and might be needed for the control/task-description files, without changing any sql in case we need an extra field, we just add a new row in the table with the field we might want/need. So here we can also add the Section field(if any) or the Enhances(some tasks also provides this field) etc. This just a first idea, I take some time these days to think of this again. > > You are perfectly right that this is a flaw inside the Blends table > > > structure. The reason for this is that when I wrote this code I did > not > > > hat the metapackage creation in mind but rather the pure set of > packages > > > involved. I have no really good suggestion whet to do here. I'll try > to > > > think about this - suggestions welcome. > > > > Ok, I will think about it better tomorrow and I will try to come up with > an > > idea. > > I guess it even goes into the direction of an additional table. I do not > see a good way to squeeze the packages that are interesting for a Blend and > the alternatives inbetween these packages into one table. > > Yes I totally agree with this. A first idea can be the following: While we parse the package dependecies from the tasks files to fill in the blend_dependencies table when we come across a package: Depends: package1 | package2 | package3 We only add the *first* package in blends_dependencies(in our case will be the package1). And then we add the rest in an extra table: table: blends_dependencies_altervatives(or something like that) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - package (primary key) | alternative - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - package1 | package2 package1 | package3 .... That way for each package in the blend_dependencies we can find its alternatives and construct again the package1 | package2 | package3 (which can go as is in the control file) and also for the task-description file we take the first available etc. This is also a first idea, I will think of it again and try to come back with a solid(maybe better) plan about these issues. Regarding the udd/blends_metadata_gathener.py and generally the udd/sql I would be happy to write patches for the new ideas/changes as soon as we agree on a solution or when we start testing(the next couple of days) :-) Kind regards Emmanouil
