Hello Andreas, On Thu, Jun 27, 2013 at 5:18 PM, Andreas Tille <[email protected]> wrote: > > > 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. > > Ahhh - seems I totally ignored this all the time. The Section field is > totally ignored inside the docs because I never realised that it is > actually used. This pushes the issue a bit higher on my todo list (for > doc and UDD importer). But once the Section will be in UDD it is surely > a very quick hack for you to add the Section to the output. Thanks for > pointing me to the Debian Edu tasks. > > > 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). > > Note for my-TODO list: > Add fields: > Section > Enhances > Leaf > Test-always-lang > to UDD importer and Blends doc. > > > > 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. > > I agree that this would work as well but it somehow spoils the > systematic of the UDD importer. Usually UDD follows a principle of not > normalised tables featuring several rows. I do not see any point in > breaking this principle for no visible gain. > > Oh, I did not know about the priciple of not normalised tables featuring several rows.So in this case that we don't have to follow strict normalization rules ,other than that , you are right there is not visible gain.
> 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. > > If you agree to my arguing I could simply implement what was written > above for my TODO-list. > > So yes based on what you said above I agree with this solution. This way will also be quite straight-forward and easy for me to add these fields to my code. > > 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. > > I somehow have the feeling that this might be a bit weak because there > might be other occurences where package1 should be not feature other > packages as alternatives but they should be added explicitly for > whatever reason. I am not quite sure I unsterstood this case. Can you give me an example? > I'm tempted to just throw into the table what is found > between the ',' in a Depends line. I'll keep on thinking about this, > thought. > > This can also be a solution for the moment, I will just have to break my query for blend-dependencies into two parts(because that way I will not be able to full outer join "blend_dependencies" with the "packages" table on "package" field, but that's ok, it can done into two parts and get the same results as we get now). > > It definitely will not harm if you read a bit in the sources. > > :-) Kind regards Emmanouil
