[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Merging libcommons-net-java packages

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.


Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: