Hi Maciej, Am 28.04.2011 um 00:10 schrieb Maciej Bliziński: > I remember a discussion about potential checks that could help identify > problems caused by package upgrades, but problems occurring with other > packages rather than the package being upgraded. If we had such automation, > it would prevent problems like this one from happening in the future. > > The basic plan would be: > > - establish a list of packages potentially affected by the planned upgrade - > run checkpkg against this set of packages and record all non overridden > errors thrown by checkpkg. The set of packages should not include the > packages from theplanned upgrade. - run checkpkg again, against a slightly > modified set of packages: this time include the new versions of the packages > to upgrade - if any new errors are thrown, it means that our upgrade breaks > other packages and it should be stopped. > > I'm sure there's a fair amount of devil to be in the details, but this check > looks doable to me. I don't have ideas what false positives would we get from > it. They would be hard to override, especially if they concern legacy > packages.
The heuristics to find out which packages could be affected sounds difficult. The other idea was to check against the whole catalog and see if more errors happen on the updated package, which required performance tuning of the code... > This mechanism would be best a wrapper around checkpkg. I don't want to add > more functionality to the core checkpkg executable unless really necessary. > > If anyone is up for implementing this functionality, I'll be happy lend a > hand and show where to get resources, e.g. json catalog representations. Best regards -- Dago _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
