Hi all, On 02.09.19 13:14, Emmanuel Bourg wrote:
Le 30/08/2019 à 05:31, tony mancill a écrit :I use Guava often at my job, and in my experience guava updates are safe. The updates don't cause regressions and only rarely include breaking API changes (which are trivial to port).Actually, Guava updates are quite the anti-thesis of the safe upgrades. Guava used to aggressively deprecate and remove features, and it broke many packages in the past. The package is full of patches restoring removed classes and methods. I spent so much time on these issues that I basically stopped updating the package in Buster. So to anyone planning to update it, please read the upstream changelog carefully as it details all the breaking changes, evaluate if it impacts the Debian package and be ready to restore the remove code or fix the reverse dependencies.
I had a first look and there are missing dependencies. It is not so very much fun to package. Also, I did not understand the motivation behind a few of the Debian patches. And some files to which these were applied to no longer exist. And there are additional (sub-)packages shipping with the source tree. On the other side, the current package is two years old. And the package I need it for happens to use the "Stream" class that was introduced only after the version currently in the archive. That does not sound to be a very exceptional idea. We should update that beast. Darn. What I had done in the past was to have the version as part of the package name. And there would be an additional package that has no version in its name that provides the symlinks to the versioned jar. The update would would then do would first update the existing package to provide a libguavac-java and a libguavac19.0-java package. And then there would be an update to provide the packages libguavac-java and libguavac28?.0-java. Packages incompatible with the update would then need to explicitly reference the 19.0 version. Best, Steffen