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).
Hi, 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 sense. > - 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. Regards, Markus [1] https://issues.apache.org/jira/browse/JCR-3912 [2] https://bugs.debian.org/798650
signature.asc
Description: OpenPGP digital signature
