Re: [GSoC] blends-gen-control hints (Was: blends-dev, gsoc 2013)
iHi 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.
> > 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.
Greetings from DebCamp
Andreas.
--
http://fam-tille.de
Reply to: