Hello Andreas,
On Fri, Jul 26, 2013 at 6:18 PM, Andreas Tille <[email protected]> wrote: > > Yes. That's the reason why you can not simply take the first > alternative. I'm not sure what might be the proper solution here. It > comes to mind to inject all real packages of an alternatives sequence > (just droping the virtual packages) which is another "interpretation" > of the technical term "alternative" - but tasksel just does not know > such things like alternatives and IMHO it is better to have a bit more > than loosing something. > > As you said I now include all the real packages of an alternative sequence in the tasksel template. Then when it comes to generate a tasksel.<arch> I use a regex where I keep the first available package of each alternative sequence and I remove the rest. It may be a little dirty but seems to work. Now tasksel template generates identical files which the tasksel.<arch> files. Only difference is in debian-science where there is a difference in the single packages sequence(sorting difference, does this cause any problem?). However, there could be some problem to install one task in case there > might be *conflicting* packages. So in case we inject "full set of > alternatives" into taskdesc files we either need to query packages table > for conflicts or we might enrich our blends tables in advance with > potentially conflicting packages. I guess this might be a very rare > case but as always its the single case amongst millions which couses > trouble for the programmer ... > > Petter, what do you think? > > This problem then may also occur in the previous {sec-}blend-gen-control(I did not quite understand the case)? That means that we should check for conflicting packages between all task-description packages(per task)? Or it is just between the alternatives? The way I solved the previous problem it is the same way we handle the alternatives in tasksel in all cases(I keep the first available and I remove the rest). > Yes. Usually Petter is very reliable. If he does not answer he is most > probable on VAC. > > ;-) Kind regards Emmanouil
