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

[Andreas Tille <andreas@an3as.eu>]

Hi Emmanouil,

On Thu, Jun 27, 2013 at 05:55:41PM +0300, Emmanouil Kiagias wrote:
> >
> > I agree that this would work as well but it somehow spoils the
> > systematic of the UDD importer.  Usually UDD follows a principle of not
> > normalised tables featuring several rows.  I do not see any point in
> > breaking this principle for no visible gain.
> >
> Oh, I did not know about the  priciple of not normalised tables featuring
> several rows.So in this case that we don't have to follow strict
> normalization rules ,other than that , you are right there is not visible
> gain.

> > So here we can also add the Section field(if any) or the Enhances(some
> > > tasks also provides this field) etc.
> > > This just a first idea, I take some time these days to think of this
> > again.
> >
> > If you agree to my arguing I could simply implement what was written
> > above for my TODO-list.
> >
> So yes based on what you said above I agree with this solution. This way
> will also be quite straight-forward and easy for me to add these fields to
> my code.

OK.  May be I will manage this evening.

> > > Yes I totally agree with this. A first idea can be the following:
> > >
> > > While we parse the package dependecies from the tasks files to fill in
> > the
> > > blend_dependencies table when we come across a package:
> > >
> > > Depends: package1 | package2 | package3
> > >
> > > We only add the *first* package in blends_dependencies(in our case will
> > be
> > > the package1). And then we add the rest in an extra table:
> > >
> > > table: blends_dependencies_altervatives(or something like that)
> > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > package (primary key)       |    alternative
> > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > package1                        |     package2
> > > package1                        |     package3
> > > ....
> > >
> > > That way for each package in the blend_dependencies we can find its
> > > alternatives and construct again the  package1 | package2 | package3
> > (which
> > > can go as is in the control file) and also for the task-description file
> > we
> > > take the first available etc.
> > >
> > > This is also a first idea, I will think of it again and try to come back
> > > with a solid(maybe better) plan about these issues.
> >
> > I somehow have the feeling that this might be a bit weak because there
> > might be other occurences where package1 should be not feature other
> > packages as alternatives but they should be added explicitly for
> > whatever reason.
> 
> 
> 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.  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.  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 ...

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.

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

Kind regards

      Andreas.

-- 
http://fam-tille.de