[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)

Hello Andreas,

On Sat, Jul 27, 2013 at 11:51 PM, Andreas Tille <andreas@an3as.eu> 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)
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
>  mpich2
<  mpich2
diff taskdesc-sec.temp taskdesc-sec/debian-science-tasks.desc.s390
>  mpich2
<  mpich2
diff taskdesc-sec.temp taskdesc-sec/debian-science-tasks.desc.s390x
>  mpich2
<  mpich2
diff taskdesc-sec.temp taskdesc-sec/debian-science-tasks.desc.mipsel
>  mpich2
<  mpich2

I just found another diff that might be more relevant: In openstudio you

--- 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 @@
  lv2fil [!hurd-i386]
+ lv2fil [!hurd-i386]
  lv2vocoder [!hurd-i386]
  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


Reply to: