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

Re: Transition from libcommons-httpclient-java to libhttpclient-java

Am 30.09.2015 um 21:56 schrieb Emmanuel Bourg:
> Le 30/09/2015 20:19, Markus Koschany a écrit :
>> I think we should file bug reports and start replacing
>> libcommons-httpclient-java with libhttpclient-java.
> I'm not convinced by the need to force this transition. Patching the
> rare security issues requires much less resources than rewriting and
> testing the HTTP code in the reverse dependencies. This time would be
> better spent on more critical transitions (bouncycastle comes to mind,
> where backporting security fixes can be really tedious due to the
> frequent refactoring).


I think you misjudge my intentions, probably because you think more from
the point of view of a Java developer than from the point of view of a
Debian maintainer or even a random contributor. This is not about
forcing people into something and you are not supposed to fix all
packages yourself. It is about identifying obsolete packages,
communicating issues to other maintainers outside the Java team,
forwarding bugs to upstream developers, documenting progress and then
you can evaluate if your goal is reachable or not. You only have a
chance to fix those kind of bugs in a timely manner, if you are
proactive and start reporting those issues early in the release cycle
and not two weeks before the next freeze approaches. We should encourage
the switch to newer upstream versions whenever possible because it
reduces the maintenance burden in the long run. It is more fun to
maintain different and up-to-date packages than keeping several versions
of the same library around forever. I also expect that we can fix more
bugs if we report such issues early and in parallel.

Although I have a good grasp of what we tend to achieve during a release
cycle and what people are working on, I am missing a good TODO list or
working plan. If you want to fix bugs, you need to know that they exist
and that something needs fixing, otherwise you can't expect help from
other people! So next time someone worked on package x with
commons-httpclient dependency, they would know for sure that their
package depends on an unsupported and obsolete library. In the simplest
case they only have to replace the dependency in debian/control. If that
doesn't work, forward the bug upstream, talk to them, explain the
situation and wait for feedback. This is far less time-consuming than
trying to fix every bug yourself.

For instance I could already switch the dependency for netbeans by just
replacing two lines in d/control. jftp doesn't even need
commons-httpclient! The build-dependency is superfluous. Of course there
are more difficult packages. I have reported a bug report for jackrabbit
yesterday. [1]

>> There are more packages which should be removed (libservlet2.5-java
>> comes to mind). More ideas?
> - libservlet2.5-java is a low priority, it's mostly a build time
> dependency and it consists mainly in codeless interfaces.

Fine that should make it rather easy to switch packages to
libservlet3.1-java. Shipping src:tomcat6 again in Stretch doesn't make

> - keeping bouncycastle up to date is important, this package is a
> potential time bomb

Agreed. However bouncycastle is actively maintained whereas
commons-httpclient is not. At least we can hope for a little support. It
doesn't need a transition either.

> - the bnd transition isn't over yet

Sure. I didn't want to waste your or someone else's time for sponsoring
two dozen packages when it is apparent that I can do it myself in the
near future.

> - asm3 should be removed since it isn't compatible with Java 8
> - tomcat7 may have to go away in Stretch
> - maven2, our most sensitive transition
> - libcommons-net2-java can be replaced by libcommons-net-java (>= 3)

Ok, that's a good list. Again the question is: How can others help to
make it happen? I believe that user tagged bug reports would be a good
way to document our progress and to raise the awareness for these goals.

> I feel like we have enough on our plate, adding even more work to avoid
> applying a patch on commons-httpclient once a year doesn't sound optimal
> to me.

Yes, that's already an impressive TODO list but I disagree with your
assumption that it is only about applying a patch to commons-httpclient
once a year. In fact I became only interested in commons-httpclient
because I provided this security patch during the Jessie freeze. My
impression was that security issues were simply ignored and this
happened again recently. [2] I am not very confident that this situation
will improve hence I will rather invest my time to get rid of
commons-httpclient because that is what its upstream developer wishes
for and what he made very clear to me.



[1] https://issues.apache.org/jira/browse/JCR-3912
[2] https://bugs.debian.org/798650

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: