On Mon, Sep 02, 2019 at 02:18:02PM +0200, Steffen Möller wrote: > 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.
We must have been lucky in avoiding the breaking parts during my day-to-day work. I still prefer the option of moving forward with the library and patching reverse dependencies, although I haven't yet evaluated the level of effort required and it could be significant. I see many invocations of ratt in my future... :) > 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. Sort of an aside, but the missing build-deps are the least fun part of it for me too. Since those packages have to go through NEW, the effort will likely take multiple months. And if I recall correctly from when I last looked at this (for 23.6), the transitive build-deps tree for this effort is non-trivial. > 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. Agreed. > 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. It would be nice if we could avoid this unless Guava 19 and Guava 28+ are completely incompatible with each other. I think it's better to be biased towards having a single, current version of the library in Debian if we can. But as Emmanuel alludes to, that's often easier said than done. And if there are significant differences in run-time behavior, then I will reverse my position. As a next step, how about we build a Guava 28 .deb locally (ignoring the build-deps problem for the moment) to assess the state of the r-deps? That should help inform us on which approach to take. I can work on this, although it likely will be about a week before I can start. Cheers, tony
signature.asc
Description: PGP signature
