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

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



Hi Emmanouil,

On Sun, Jul 28, 2013 at 06:57:35PM +0300, Emmanouil Kiagias 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.

Ahh, OK - that's definitely no problem.
 
> > 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.

I attached a tarball.

> > 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.

Hmmm, seems to be OK.

> > 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 :-)

Fine.

Kind regards

        Andreas.

-- 
http://fam-tille.de

Attachment: ctrl+taskdesc.tar.gz
Description: Binary data


Reply to: