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

Hello Andreas,

On Thu, Jul 4, 2013 at 8:07 PM, Andreas Tille <andreas@an3as.eu> wrote:

While beeing offline again (some talk rooms are not covered by WLAN) I
finally implemented my idea of the alternatives table which is now even
enhanced by distribution and component columns according to the fact
whather at least one alternative is in Debian main or contrib/non-free,
etc. I think this implementation does in no way conflict with your idea
and thus I'd suggest to keep this as long as we are not sure what way we
might go. My idea was to enable an alternatives table that can fully
replace the dependencies table and you might try some tests whether this
enables the same results as with your implementation where you only use
the "lookup alternatives" way. This experiment might lead to the right
solution, IMHO. The weak part in my approach remains that there is no
good way to find out whether the distribution / component information is
valid for a given architecture and this could be an advantage for your
approach. If this turns out to be the case we might strip the table
again some bit in a final stage.

:-) that's perfectly fine, I will do it both ways and then we can decide how it will be in final stage.

I think I git your point but for completenes here is now all information:

udd=# SELECT * from blends_dependencies_alternatives where alternatives like '%k3b%' or alternatives like '%brasero%';
blend | task | alternatives | dependency | distribution | component
-------------+---------------+--------------------+------------+--------------+-----------
debian-edu | desktop-other | k3b | brasero | r | debian | main
debian-edu | desktop-other | k3b-i18n | brasero | r | debian | main
debian-ezgo | multimedia | k3b | d | debian | main
debian-ezgo | multimedia | brasero | d | debian | main

> Also I have
> one question: why does this table contain the k3b and brasero packages as
> standalones? what I mean is that the blends_dependencies_alternatives in
> the alternatives field should only have strings into this format "package1
> | package2" so strings which contain the logical OR "|" inside them.

Well, this was my idea from the beginning and I obviosly failed to
explain without implementing it - hope it becomes clear now. I went the
abstract route that even single packages are some "special case" of
alternatives. This is was I tried to say initially by "storing
verbosely all what you find between ',' signs" which might be single
packages or '|' separated sets of packages ("real" alternatives).

When thinking about it this approach might spoil your approach a bit -
but this could easily solved by a view showing only

SELECT blend, task, alternatives, dependency from blends_dependencies_alternatives where alternatives like '%|%' ;

which should exactly reproduce the content of your proposed table.

Ok now it became perfectly clear :-), having this table, as I said above, I can do it both ways.

Lets create the according control files
and check whether they reproduce the content of the tasks file. BTW, for
experimenting with side case you can always experiment with the "fun"
Blend - which exists just for debugging fun.

Ok, thanks I didn't have in mind the "fun" Blend.

> > udd=# SELECT (SELECT count(*) from blends_dependencies_alternatives) as
> > altcount, (SELECT count(*) from blends_dependencies) as depcount ;
> > altcount | depcount
> > ----------+----------
> > 5764 | 5022
> >
> > I'd like to check why this is the case to this extend before I commit
> > this to the public Git repository.

Problem solved.

:-)

> This is probably happening because the importer might include all the
> packages into the blends_dependencies_alternatives along with the
> alternatives into the format "package1 | package2". Like the results you
> got above:

Well, the alternatives table should have "a lot" of entries but simply
not more than the dependency table. This is now fixed:

udd=# SELECT (SELECT count(*) from blends_dependencies_alternatives) as altcount, (SELECT count(*) from blends_dependencies) as depcount ;
altcount | depcount
----------+----------

4987 | 5080

> So the reason you get more lines in the alternatives table is (maybe)
> because the 5022 single package dependencies from blends_dependencies
> table are also added in the blends_dependencies_alternatives and you also
> add the strings which contain "|" so the raw strings "package1 | package2"
> which maybe are 742 (5764- 5022). So the blends_dependencies_alternatives
> should not contain single packages only boolean "|" package strings

The reason was actually that in the dependency table importer those packages
that are not inside UDD at all are simply thrown away. Obviosly there are
a lot of them - because after I implemented this for the alternatives I've
got the numbers as expected. Now some more reasonable number because the
"view" above has 69 entries where some have more than one element in the
alternatives string - so a difference of 93 makes perfectly sense (without
having checked the actual numbers).

Ok knowing this, also made things more clear.

> In openjdk they do it more or less the same way as you say above, so I
> think if we can also do it that way :-)

So it seems at least in this respect I was not totally insane. ;-)

First talk provided. ;-)

;-)

Tomorrow I will try to finish at least one way(yours or mine) using the new table. For sure the weekend I will cover up the lost day(yesterday that I didn't work) and I will finish up both ways.

Thanks for your fast feedback :-)

Kind regards

Emmanouil