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

[Andreas Tille <andreas@an3as.eu>]

[strange, I thought I have answered this yesterday - may be the weak
 network has eaten some Bytes ...]

On Wed, Aug 07, 2013 at 10:53:38PM +0300, Emmanouil Kiagias wrote:
> > This would be my first approach to handle it.  However, we should try to
> > flag that we "automatically invented" some Dependency which was not
> > explicitly specified.
> >
> OK I understand the case, it's interesting, replacing the dependency with
> the latest might be a little tricky. I will look into it.

Yes, it's definitely tricky.  That's why I did not touched it before. ;-)

> > I think to check the replaces might be a good catch to detect these.
> >
> OK so I will start from there.

Fine.

> While looking into the blends source I saw into the BUGS file:
> "blend-gen-control does not regard versioned depends".

That's a good catch!!! While I personally do not have any practical
usage for versioned depends (which finally is the reason why I did not
touched this topic and even forgot about the second part of the entry in
the BUGS file it surely is a reasonable enhancement.  In case there is
no example for a versioned depends inside the real data we could play
with this in Debian Fun.

> Once we handle the
> above cases I can also deal with that. With the new code it won't be
> difficult to also regard the version when looking for existing packages.

+1

The more I deal with this UDD based Blends stuff the more I'm happy
about it.  It was quite easy to rewrite the bugs part of the websentinel
which in its currently active implementation had some main flaws and I
never found the enthusiasm to fix this but now it became quite simple.
This somehow motivates me to even put all the data about prospective
packages and other metadata into UDD and also generate tasks pages that
way.

> I
> can imagine an extra field into blends_dependencies containing the
> version(if specified) and then a check with the packages UDD table, column
> "version".

+1

> Also I think that before I proceed to code the above cases we should choose
> a way to go the moment: blend-gen-control or sec-blend-gen-control. So I
> can focus working on one instance and once we need to make tests or we want
> to change the implementation I can then deploy the same changes to both of
> the scripts. There is also the option to change them in parallel (as I am
> doing for the moment).

Feel free to pick one of the implementations.  If both are leading to the
same result it should be no problem.  My intuition has a slight preference
for sec-blend-gen-control but there is no strong reason for me to put this
intuition onto you.  Just decide for one and if it turns out to cause some
trouble we might fallback to the other version.

> I will also soon attend there :-) . I am looking forward meeting you. It
> will also be a good opportunity to discuss about the project in person.

:-)
 
> PS: Tomorrow I am travelling to Switzerland so I will be offline.

In case you might read this - enjoy the trip (and make sure you have some
rain clothes with you ...)

Kind regards

         Andreas.

-- 
http://fam-tille.de