ApacheDS specific JDBM Implementation
jdbm-1.0-apacheds.patch.tar.gz

I would like to request permission to bundle forked code from jdbm [1] in apacheds-jdbm package [2].

apacheds-jdbm contains multiple files forked from ​jdbm [1] (no more available in Fedora >= 23). This file is included in apacheds-jdbm source repository and maintained as part of the project. Since the file was forked, apacheds-jdbm upstream implemented a few features, removed some cruft and reformatted source.
I have attached a patch showing the changes made by the developers

[1] http://jdbm.sourceforge.net/
[2] ​https://bugzilla.redhat.com/show_bug.cgi?id=1243758

Could you answer the std. bundling questions?

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions

Replying to [comment:3 james]:

Could you answer the std. bundling questions?

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions

Has the library behaviour been modified? If so, how has it been modified?

Yes, see attachment

Why haven't the changes been pushed to the upstream library?

Upstream is in maintenance mode (bug fix only) for the original library ApacheDS at the moment still use this customization of jDBM (in the "distant" future should be replaced by ​https://directory.apache.org/mavibot/)

Have the changes been proposed to the Fedora package maintainer for the library?

No sense to propose these changes

Could we make the forked version the canonical version within Fedora?

yes

Are the changes useful to consumers other than the bundling application?

yes

If so why aren't we proposing that the library be released as a fork of the upstream library?

sorry, I had not thought. but to avoid that someone confused, like a duplicate of the original library, I opened this reporting

Doesn't this also bundle jdbm2?

Replying to [comment:5 orion]:

Doesn't this also bundle jdbm2?

No, is work done based on jdbm1. It has nothing to share with https://code.google.com/p/jdbm2 (same autor)

https://github.com/jankotek/JDBM3
https://github.com/jankotek/JDBM4

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-09-03/fpc.2015-09-03-16.00.txt):

• 564 Bundling exception for apacheds-jdbm (geppetto, 16:24:29)

• LINK: https://fedorahosted.org/fpc/ticket/564 (geppetto, 16:24:29)
• ACTION: Given you said the changes are good for everyone, and the
  forked version could be canonical. Can you become the Fedora
  maintainer and use your version? (geppetto, 16:32:11)

Replying to [comment:7 james]:

We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2015-09-03/fpc.2015-09-03-16.00.txt):

• 564 Bundling exception for apacheds-jdbm (geppetto, 16:24:29)

• LINK: https://fedorahosted.org/fpc/ticket/564 (geppetto, 16:24:29)

• ACTION: Given you said the changes are good for everyone,
  definitely for those who want to use ApacheDS

  and the forked version could be canonical. Can you become the Fedora
  maintainer and use your version? (geppetto, 16:32:11)

users who want to use JDBM should know that has been changed upon by mapdb [1], and

use this last [2]

[1] https://github.com/jankotek/mapdb

[2] http://pkgs.fedoraproject.org/cgit/mapdb.git/

I am not sure whether unbundling jdbm1 library is worth it in this case. The last (Maven) release of the library was on August 11, 2005 1. It is used mostly by older releases of the Apache DS project 2. To be more precise, it looks like the last version of the Apache DB which depends on pristine version of the jdbm1 library is 1.0.2 3, released on May 25, 2007. The direct dependency then disappeared and I assume that it's the time when they started using their own fork.

So why is it not worth unbundling in my opinion?
- the library is not widely used in open source Java projects (we know about 10 projects in total, 7 of which are older releases of Apache DS), therefore the chances are that unbundled lib will always be used only by Apache DS in Fedora
- Java developers doing their work on Fedora typically don't use packaged Java libraries so they can't benefit from this work (there is a good reason for it, I don't use them either)
- I don't think that we would be able to "sell" these changes to upstream - trying to convince them to unbundle the library doesn't make sense. The whole apacheds-jdbm project is basically fork of the old jdbm library, and Apache maintains it to this day. If developers want to use jdbm1 from some reason, they should use apacheds-jdbm, the original project died long time ago.

As a Java SIG member, I would recommend to grant bundling exception in this case.

As FPC is no longer in the business of approving bundling requests for packages outside the critical path, you may bundle as you wish. Please do add the proper Provides: bundled(jdbm1) tag to your package.