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

[Andreas Tille <andreas@an3as.eu>]

Hi Emmanouil,

On Fri, Jul 26, 2013 at 07:27:02PM +0300, Emmanouil Kiagias 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?).

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?

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.

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

Yes.  This is not connected to the control file creation at all and the
taskdesc file creation is in both cases more or less the same.  It just
popped up to my mind when I've thought about this.  I would even think
that this aspect is not regarded in the old way to create taskdesc files
because the information what is used to create these is insufficient to
even check conflicts.

> That means that  we should check for
> conflicting packages between all task-description packages(per task)? Or it
> is just between the alternatives?

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.

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.

Kind regards
 
    Andreas.

-- 
http://fam-tille.de