Hello Andreas On Wed, Aug 7, 2013 at 3:25 PM, Andreas Tille <[email protected]> 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
