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

Hello Andreas,

On Thu, Jun 27, 2013 at 6:20 PM, Andreas Tille <andreas@an3as.eu> wrote:

> I am not quite sure I unsterstood this case. Can you give me an example?

I'm looking at debian-edu/tasks/desktop-other. This has:

Depends: gecko-mediaplayer | mozilla-mplayer | kaffeine-mozilla | mozilla-plugin-vlc | totem-mozilla

Recommends: default-jre | openjdk-6-jre, icedtea6-plugin

I would turn this into

blend | task | package_s_ | dependency | distribution | component
-----------+---------------+---------------------------------------------------------------------------------------------+------------+--------------+------------
debian-edu | desktop-other | gecko-mediaplayer | mozilla-mplayer | kaffeine-mozilla | mozilla-plugin-vlc | totem-mozilla | d | debian | main
debian-edu | desktop-other | default-jre | openjdk-6-jre | d | debian | main
debian-edu | desktop-other | icedtea6-plugin | d | debian | main
...

So you can take over 1:1 from package_s_ (a suggestion more reasonable
column name would be welcome as well as a decision whether *this* table
should be named blends_dependencies and the other currently existing
table rather blends_packages).

Your initial suggetsion would fail say for debian-multimedia where
it might be perfectly possible to have some

Depends: gecko-mediaplayer

without any alternative (or whatever). Your suggestion to just join
the alternatives behing gecko-mediaplayer would break and you could
also find different sequences of alternatives - so I think we somehow
need to preserve the content of the tasks files in a clever way.

Ah, yes I now understand the problem in my idea. So in case we did it this way(just wondering) we would need 3 keys(blendname, task, package1) to identify the alternative package in order to avoid the problem you mention?( instead of having only the package1 for primary key)

The
only chance that might safe us from using two tables would be some
view that splits up the '|' in the table I mentioned above and adds
extra rows for every alternative. This could require some bit of
SQL magic. But all in all our tables are not really expensive and if
you do not know such clever SQL tricks that turn the table above into

blend | task | package | dependency | distribution | component
-----------+---------------+--------------------+------------+--------------+------------
debian-edu | desktop-other | gecko-mediaplayer | d | debian | main
debian-edu | desktop-other | mozilla-mplayer | d | debian | main
debian-edu | desktop-other | kaffeine-mozilla | d | debian | main
debian-edu | desktop-other | mozilla-plugin-vlc | d | debian | main
debian-edu | desktop-other | totem-mozilla | d | debian | main
debian-edu | desktop-other | default-jre | d | debian | main
debian-edu | desktop-other | openjdk-6-jre | d | debian | main
debian-edu | desktop-other | icedtea6-plugin | d | debian | main
...

(which is our current table) we might go with two tables.

To be honest I don't know such sql tricks, I have never dealt with something similar before, but as they say there is always a first time :-)

I'm sure
there will be a way to create a view to get this but it is error prone
and definitely not fast for simply saving some bytes on a hard disk ...

Yes it should be a way, I will look it up (I am curious to find out how this can be done) but as you said it will probably be error prone.

However, I think we should start with some documentation about the
motivation for those two similar tables to make sure people will not
stumble upon it in future.

Yes I agree I will document this tomorrow. Where should I documented it?

For the beginning I will write a readme file(in some other syntax?)

> > I'm tempted to just throw into the table what is found
> > between the ',' in a Depends line. I'll keep on thinking about this,
> > thought.
> >
> This can also be a solution for the moment, I will just have to break my
> query for blend-dependencies into two parts(because that way I will not be
> able to full outer join "blend_dependencies" with the "packages" table on
> "package" field, but that's ok, it can done into two parts and get the same
> results as we get now).

I admit I do not understand this paragraph (in exchange to mine which
was surely not understandable).

haha, now that i see it again you're right, it's not understandable. So what I mean (I will try to make sense this time) is that:

In case we only use one (let's say) blend_dependencies table with a column like package_s_:

then we would not be able to join it with the UDD "packages" table using the package_s_ as joining condition. So in that case with a first query we get the package_s_ information (get the alternatives) and with a second query(eg like you said in your way with a view) we split the "|" in the above table into something that can be joined with packages table (in order to get the same info we get now with blends-gsoc/sql/blendsd). That's why I said "break"(split) my sql into two parts. To be honest I was a little thoughtless when I wrote this paragraph, i did not have clear in my mind how it could be done but anyway your idea fully covered this part(and also made things more clear).

I will start from documenting the motivation about the extra table(two similar tables).

Kind regards

Emmanouil