* Emmanuel Bourg: > There is another point worth discussing I think. When we want to fork a > package foo 1.0 because the version 2.0 is incompatible, do we: > > 1. duplicate the package foo as foo-1 and upgrade foo to the version 2. > Every reverse dependency that doesn't work with the version has to be > updated to use the new package foo-1. > > 2. fork and upgrade the package foo as foo-2. The package that need the > new version depend on foo-2 and the other remain unchanged. > > While the solution 2 looks easier, it causes some embarrassing > situations when foo-2 is upgraded. If the version 3 is compatible with > the version 2 we end up with foo-2/3.0-1. We already have some > packages in this case, like libasm4-java/5.0.3-1 and > libplexus-utils2-java/3.0.15-1.
I favor the second option, simply because it forces less work on package maintainers. The source package name is largely irrelevant. The number that is part of the binary package name only indicates that the package adheres to a specific API/ABI compatibility level. One could theoretically pick any arbitrary combination of letters and numbers instead, the only important issue is that a binary package doesn't break API/ABI promises that have been (implicitly) given by previous versions of the same binary package. If there are concerns that users mistake the API/ABI compatibility level for the major version of a library, it may be a good idea to put a clarification such as "This package is compatible with versino x of the FOO library." into the description of the libFOOx-java package. I think that I am going to name the Guava package "libguava18-java" (without the extra hyphen), for consistency reasons with the examples you provided and because it looks less like a version number than in "libguava-18-java". I think that we are close to over-thinking it at this point. Most of our users probably won't care at all about the naming issues. > Regarding Guava 18, considering that only two packages failed to build > with the new version, I'd prefer creating a guava-libraries-17 package > and upgrading the main package to the version 18. Again, this means extra work on other packages. (Two packages in this concrete example may not seem much, but in the general case it may be much more.) Additionally, not having to figure out right away what other packages are affected by an API/ABI-breaking new version is a Good Thing. After all, those reverse dependencies may be caught up in a transition. And for this concrete example: Breaking dependencies this close to the freeze seems like a really bad idea to me. Cheers, -Hilko -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87oaswru7a....@msgid.hilluzination.de
