#2036 F30 Change: Deprecate Apache Jakarta Commons HttpClient
Closed: Accepted 5 years ago by bowlofeggs. Opened 5 years ago by bcotton.

Mark Apache Jakarta Commons HttpClient software packages as deprecated.


I count the vote as (+3,0,-0). Since this was submitted right before the holidays, I will wait until Thursday to process this Change proposal as accepted.

-1

I'm against adding useless additional virtual deps into the repodata. The proposal does not describe any way in which those Provides would be used.

Frankly, I'd much rather see this moved to F31 with an immediate announcement and multiple reminders up to the F30/F31 Branch. Then, remove these packages immediately once Rawhide becomes F31. Adding the deprectation Provides just wastes space.

The Provides would be used as in https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ - I guess that guideline should be revised if those virtual provides are not supposed to be used.

Hmm, I wasn't aware of that guidelines page (thanks for the link), but I disagree with it and I think FESCo should make a call on whether to remove that page.

I propose that this section of the Guidelines be removed entirely. It adds nothing to the distribution except additional garbage in the repodata. I don't think we can realistically expect that our packagers check the virtual Provides of every package they depend on (I know I do not). I think deprecation can be limited to a series of announcements about which Fedora release is going to drop a package followed by... dropping the package. I'd also propose that if possible, such things should occur as part of the branching event for any approved major removal such as these.

The virtual provides are to be checked automatically and FedroaReview is currently gaining the functionality. However we are OT here. If FESCo wishes to ask FPC to remove that guideline, I guess you can always open a separate ticket.

For the reference, here is the FPC ticket for adding it: https://pagure.io/packaging-committee/issue/723

Since there's a -1, I will hold off on processing this Change proposal until after Monday's FESCo meeting.

Since we want to embrace automation, we need to provide machine-readable information. Using virtual provides for deprecation sounds to me like a good idea even if not enough tools are consuming it already. It sounds like it would also be great for automated tests to gate updates when they introduce new dependencies on deprecated provides.

Since we want to embrace automation, we need to provide machine-readable information. Using virtual provides for deprecation sounds to me like a good idea even if not enough tools are consuming it already. It sounds like it would also be great for automated tests to gate updates when they introduce new dependencies on deprecated provides.

At present, I'm not aware of any tools using this information, which is why I'm reticent to allow this. If someone wants to write a CI test that checks every (sub-)package in a Bodhi update to see if any of its dependencies include a special Provides: deprecated() virtual dependency, okay. I guess I could see us adopting this approach.

At the moment, however, it's only there for manual inspection and it requires a conscious effort on the part of packager of the dependent software to know to do this and to actually do it. This packager also has a vested interest in not doing so, since it would translate into more work for them.

Realistically, even if we added that test, it could have only two outcomes:

  • The test fails non-fatally and the packager ignores it because as long as it works, who cares, right?
  • The test fails and the package is not permitted to push to stable, which is functionally identical to not having the dependency in the distro at all, except that you find out about it much later in the process and are angry about it.

In either case, it seems to me that removal from the distro at a well-documented and announced date is a better solution all-around. It doesn't require wasting space in the repodata and it reveals itself much earlier in the release process.

Realistically, even if we added that test, it could have only two outcomes:

The test fails non-fatally and the packager ignores it because as long as it works, who cares, right?
The test fails and the package is not permitted to push to stable, which is functionally identical to not having the dependency in the distro at all, except that you find out about it much later in the process and are angry about it.

As long as the test checks only for new dependencies, this allows old stuff to continue to use the deprecated features until they are fully moved.

In either case, it seems to me that removal from the distro at a well-documented and announced date is a better solution all-around. It doesn't require wasting space in the repodata and it reveals itself much earlier in the release process.

Where would you document this and keep this updated? The information can also be used to provide a documentation website. Not sure what you mean with the release process. If someone now spends time on using a dependency and then after 6 months the dependency is removed, how is this better that to get this information as soon as there is an update that introduces the dependency. Also the fedora-review approach helps to catch this even before pacakges are added to the distribution (this also needs machine-readable data).

If the information about package deprecation is to be kept somewhere, Provides seems like a very good place to do it. Announcements to the mailing list are all great, but impossible for automatic tooling to consume. If fedora-review learns to check, which shouldn't be to hard, this should work nicely. So in general, I think the mechanism is useful.

In this particular case, there's a number of packages which depend on jakarta-commons-httpclient. Just dropping the package immediately seems impossible, and the dragged-out deprecation process necessary.

$ dnf repoquery --whatrequires jakarta-commons-httpclient --release rawhide --qf '%{name}'  
arduino
axis2
eclipse-mylyn
eclipse-recommenders
fop
hadoop-common
hadoop-tests
jakarta-commons-httpclient-demo
java-oauth
jenkins-core
jenkins-webapp
jersey1-contribs
maven-docck-plugin
olfs
opensaml-java-openws
openstack-java-resteasy-connector
pki-base-java
rome-fetcher
rome-propono
sbt
solr3

Let's ask the maintainers: @ctubbsii, @denisarnaud, @milleruntime, @giallu, @chitlesh, @patches, @msrb, @willb, @skottler , @mharmsen, @dmoluguw, @cipherboy, @edewata, @kwright, @vakwetu, @gil, @goldmann, when can you drop the dependency on jakarta-commons-httpclient from your packages?

Metadata Update from @bowlofeggs:
- Issue tagged with: meeting

5 years ago

We will discuss this in the FESCo meeting on Monday at 15:00UTC in #fedora-meeting-1 on
irc.freenode.net.

The proposal does not describe any way in which those Provides would be used.

These Provides would be used by:

  • Java SIG members (at least proposal submitter) that would monitor new dependencies on deprecated packages - in case of new dependency appearing, packager introducing them would be notified about violation of packaging guidelines and asked to revert the change,
  • every packager during package review - checking dependencies on deprecated packages is already a mandatory step of package review process and dependency on a deprecated package is a blocker for adding new packages to Fedora
AGREED: APPROVED (+9, 0, -0)

Metadata Update from @bowlofeggs:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

5 years ago

Login to comment on this ticket.

Metadata