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

Hello Andreas

On Wed, Aug 7, 2013 at 3:25 PM, Andreas Tille <andreas@an3as.eu> wrote:

Hi Emmanouil,

On Mon, Aug 05, 2013 at 11:49:40PM +0300, Emmanouil Kiagias wrote:
> With a quick search in UDD I found a random example:
>
> package
> - - - - - - - - - - - - --
> sugar-artwork-0.96
> sugar-artwork-0.84
> sugar-artwork-0.88
>
> This should be a problem when such packages appear into the same task.

Yes, but if the tasks file contains for instance

sugar-artwork-0.90

the dependency would not be fullfilled at all. So replacing it by

sugar-artwork-0.96

would make sense.

> Then
> it is an error in the task file, similar to the duplicate packages
> case(which are actually duplicate with just different version) and it
> should be handled(eg print a warning into a log file)

Logging a warning should be the first thing to do.

> from the
> blends_metadata_importer(with the current blends_metadata_importer such
> packages are included into the blends_dependencies).

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.

> > B) Packages that are not found inside the archive but look "suspicious"
> > for changed name (bumped number inside the name)
> >
> >
> So packages which are updated and their name has changed? I am thinking of
> keeping a list with the debian/main missing packages(not found for any
> architecture). Then I will check for those packages if they appear into the
> "replaces" column of packages UDD table. That way we can make sure that
> they are really missing and not just renamed because of an update. In this
> case we can keep a warning log same as you do for the duplicate packages.
> And by checking the log for such cases , task files can be updated with the
> new names of the updated packages.

I think to check the replaces might be a good catch to detect these.

OK so I will start from there.

While looking into the blends source I saw into the BUGS file: "blend-gen-control does not regard versioned depends". 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. 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".

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

Greetings from DebCamp

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.

Kind regards

Emmanouil