As I've mentioned a few times in the past, all Jakarta software is dead and gone, unmaintained upstream for several years now, and should be removed from Linux distributions. Most Jakarta things have modern, maintained Apache equivalents that are (near) drop-in replacements, and most of these switches have already been made. My understanding is that everything still using jakarta-commons-httpclient should be portable to httpcomponents-client, which is the modern Apache equivalent. It's just up to someone to do the porting. Based on a check of all of our SPEC files that Thierry did last Christmas: https://ml.mageia.org/l/arc/dev/2015-12/msg00483.html these are the only packages still using jakarta-commons-httpclient: ant-contrib.spec (BR jakarta-commons-httpclient) apache-ivy.spec (BR jakarta-oro, BR jakarta-commons-httpclient) axis.spec (BR jakarta-oro, BR/R jakarta-commons-httpclient) fop.spec (R jakarta-commons-httpclient) hadoop.spec (BR/R jakarta-commons-httpclient) jenkins.spec (R jakarta-oro, R jakarta-commons-httpclient) libreoffice.spec (R jakarta-commons-httpclient) narayana.spec (BR jakarta-commons-httpclient) Finally, oro (jakarta-oro) and regexp are two other Jakarta packages still in the distro that are used by things, but I don't know if there are equivalents for these, or if so, what they are called.
CC: (none) => geiger.david68210
I agree that old and unmaintained code should be dropped. I'm all for it, when possible. Unfortunately, as far as I know, httpcomponents-client (4.x) API is *not* compatible with jakarta-commons-httpclient (3.x). Porting dependant packages would require significant work and upstream cooperation. Any help is of course welcome. jakarta-oro and regexp won't be easy to remove either. But there are some old and unmaintained packages, which should be much easier to get rid of, for example werken-xpath or avalon-framework.
CC: (none) => mizdebsk
It will require some Java programming work and cooperation with upstream, but it should be done. I don't know how big the API changes are or how significant the work would really be, but again, just from what I've read, it should be do-able, it's just a matter of someone (or multiple someones) having the time to work on it. werken-xpath is indeed no longer needed, so we can drop that. Thanks for pointing that out. avalon-framework is currently needed by several things, including at least: avalon-logkit fop freemind hadoop jets3t-app publican
(In reply to David Walser from comment #2) > avalon-framework is currently needed by several things, including at least: > avalon-logkit > fop > freemind > hadoop > jets3t-app > publican Most of these are false-dependencies, IIRC. I'll see what can be done about fixing them.
Raising to release blocker for Mageia 7. We shouldn't keep this around forever.
Priority: Normal => release_blocker
Target Milestone: --- => Mageia 7CC: (none) => ouaurelien
Hi, This is release_blocker for a reason. Making Mageia even better than ever is best direction. In order to do right thing, this bug should be examined and fixed as soon as possible. Packagers, please change the status to "Assigned" when you are working on this. We will make a decision on the relevance of the release_blocker tag on 1st October 2020 QA meeting.
Target Milestone: Mageia 7 => Mageia 8
akarta-commons-httpclient-3.1-27.mga8.src.rpm Still here. Ping.
I saw in Bug 27389 that you dropped this, but I didn't see it get obsoleted. It really should be obsoleted by httpcomponents-client, as that is its direct replacement.
done
Resolution: (none) => FIXEDStatus: NEW => RESOLVED