Comment below... On 08/05/2014 12:46 AM, Emmanuel Bourg wrote: > Hi all, > > I'd like to upgrade Apache Commons Net in Debian to the latest 3.x > release, but the situation regarding this library is a bit complicated. > We have currently 3 source packages: > * libcommons-net-java/1.4.1-2 (oldstable only) > * libcommons-net1-java/1.4.1-5 (stable, testing, unstable), it generates > an empty libcommons-net-java package and installs commons-net.jar in > /usr/share/java to preserve the compatibility. The package doesn't > provide Maven artifacts. The Javadoc is embedded with the main binary > package. > * libcommons-net2-java/2.2-2 (oldstable, stable, testing, unstable), the > latest 2.x release, it installs commons-net2.jar and the Maven > artifacts. The documentation is packaged separately in > libcommons-net2-java-doc. > > Commons Net 3.x is compatible with the version 2.x and instead of > uploading a version 3.x of libcommons-net2-java I'd like to take this > opportunity to simplify the packages. > > I checked the reverse dependencies on libcommons-net-java and > libcommons-net1-java and they are compatible with the latest version of > commons-net: > > * ant (ok since Ant 1.8: > https://issues.apache.org/bugzilla/show_bug.cgi?id=47669) > * jakarta-jmeter (ok, upstream uses commons-net 3.3) > * ipig (looks ok, upstream uses commons-net 3.1) > * salliere (builds fine with commons-net 2.2) > * spring-build (builds fine with commons-net 2.2) > * netbeans (couldn't check due to #713182, but looks ok) > > So I think it's safe to return to a single package. Here is the plan I'd > like to propose: > > 1. Generate the libcommons-net-java package from > src:libcommons-net2-java. The package will depend on > libcommons-net2-java and contain a link from > /usr/share/java/commons-net.jar to /usr/share/java/commons-net2.jar. > Mark the new libcommons-net-java with Conflicts/Replaces on > libcommons-net1-java (<< 1.4.1-5~) > > 2. Upload src:libcommons-net1-java without libcommons-net-java and drop > the Conflicts/Replaces on libcommons-net-java (<< 1.4.1-4~) > > 3. Rename src:libcommons-net2-java to src:libcommons-net-java. I'll > migrate the package to Git in the process and merge the history of the 3 > source packages into a single repository. I'm not sure if reusing the > old src:libcommons-net-java will require a run through NEW. > > 4. The binary package libcommons-net-java becomes the main package, and > libcommons-net2-java the transitional package: > * libcommons-net-java now contains the real > /usr/share/java/commons-net.jar and installs the 'debian' Maven > artifacts instead of 2.x > * libcommons-net2-java: depends on libcommons-net-java and contains > only symbolic links. It provides commons-net2.jar and the '2.x' Maven > artifacts > > 5. Rename libcommons-net2-java-doc to libcommons-net-java-doc (this will > go through the NEW queue) > > 6. Update the reverse dependencies to replace libcommons-net1-java and > libcommons-net2-java > > 7. Request the removal of libcommons-net1-java and libcommons-net2-java > > What do you think?
Hello Emmanuel, I appreciate that you're looking at taking on this complexity to clean up the situation. My only comment is to consider whether it would be easier to upload a src:libcommons-net3-java that otherwise follows the trajectory you describe for the src:libcommons-net2-java package. Then, instead of having to do a rename in step 3, you could simply delete src:libcommons-net2-java once src:libcommons-net3-java provides/conflicts sufficiently to drop the previous two older source packages. Aside from (potentially) saving a step, having net3 might be better self-documenting if we find ourselves wanting a net4 package in the archive at some point down the road. Cheers, tony
signature.asc
Description: OpenPGP digital signature
