Hello Andreas,
On Sat, Jul 27, 2013 at 11:51 PM, Andreas Tille <[email protected]> wrote: > > I think the sorting is no practical problem even if I think that for the > development it makes perfectly sense to have a strict alphabethical > order to be able to compare easily makes sense. Can you provide the > diff where the sorting is different? > > The sorting diff appears in debian-science where we have in the tasksel template: (before converting the template the packages are sorted) .. netcdf-doc openmpi-bin [!s390 !s390x !hurd-i386 !mipsel !mips] | mpich2 [!hurd-i386] openmpi-doc | mpich2-doc ... So for the archs: s390, s390x, mipsel, mips from the "openmpi-bin | mpich2" alternatives relation, mpich2 will come active in the taskdesc file and it will appear between "netcdf-doc" and "openmpi-doc | mpich2-doc" where it is in wrong sorting order. Here are the diffs: diff taskdesc-sec.temp taskdesc-sec/debian-science-tasks.desc.mips 934a935 > mpich2 940d940 < mpich2 diff taskdesc-sec.temp taskdesc-sec/debian-science-tasks.desc.s390 865a866 > mpich2 871d871 < mpich2 diff taskdesc-sec.temp taskdesc-sec/debian-science-tasks.desc.s390x 845a846 > mpich2 851d851 < mpich2 diff taskdesc-sec.temp taskdesc-sec/debian-science-tasks.desc.mipsel 940a941 > mpich2 946d946 < mpich2 I just found another diff that might be more relevant: In openstudio you > get: > > --- taskdesc.template 2013-07-27 20:09:37.000000000 +0200 > +++ taskdesc-sec.template 2013-07-27 20:09:40.000000000 +0200 > @@ -382,6 +382,7 @@ > lv2-c++-tools-doc > lv2core > lv2fil [!hurd-i386] > + lv2fil [!hurd-i386] > lv2vocoder [!hurd-i386] > slv2-doc > slv2-jack [!hurd-i386] > > > ... at least with my copy of UDD on my laptop which is not in sync with > official UDD. > > I have no idea how it can happen that an entry is duplicated - but that > should be avoided. > > That's strange, my copy of UDD does not show these differences. Can you attach me control/control-sec/taskdesc/taskdesc-sec files from your copy of UDD, it help me to understand where the problem is. > > IMHO only between alternatives. I would regard a task broken by design > if it contains independent conflicting packages and we can safely ignore > such cases. However, the nature of alternatives might include a strict > "either or" relation between the alternatives and if we check this we > can be sure that we are on the safe side. > > > 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). > > Hmmm, while just taking the first available is safe against conflicts > I've thought from what I understand from your explanation above you > would follow the "we take over all existing / real packages alternatives > into taskdesc" strategy. This would be needed for instance if the first > alternative is available only on architecture A and the second only on > B. If you just take over the first alternative it simply gets stripped > from the taskdesc file if you build on architecture B ... even if we > could provide some alternative. > > Actually in the taskdesc.template I include *all* the real packages alternatives. When it comes to generate a taskdesc.<arch> from the taskdesc.template only then I only keep the first available(if any) from the alternatives, thus the problem you mention is handled. For example: Let's say we have in taskdesc.template: openmpi-bin [!s390 !s390x !hurd-i386 !mipsel !mips] | mpich2 [!hurd-i386] and we want to create a taskdesc for arch s390. If we straight do: grep -vE "\[\!s390\]|\[\!s390 | \!s390 | \!s390\]" | sed -e 's/\[.*\]//;s/[ \t]*$//' taskdesc.template this will remove the whole line of the alternatives(which is wrong because mpich2 is available for s390). So I first convert the line: openmpi-bin [!s390 !s390x !hurd-i386 !mipsel !mips] | mpich2 [!hurd-i386] to mpich2 [!hurd-i386] (I only keep one package from the alternatives relation/the first available of the target arch ) and then I do the grep -v/sed to clean up the taskdesc.template. BTW, for the sake of testing we could just seek for two conflicting > packages and inject these as alternatives in a task of Debian Fun. > > I included in Debian fun all the problematic cases we have along with some conflicting packages as alternatives :-) Kind regards Emmanouil
