From Fedora Project Wiki

No edit summary
m (Removing the categories so it doesn't show up in searches. This has been superseded by https://fedoraproject.org/wiki/Changes/Libdb_deprecated)
 
(8 intermediate revisions by one other user not shown)
Line 36: Line 36:


== Detailed Description ==
== Detailed Description ==
We would like to remove libdb from Fedora in future, because BerkeleyDB 6.x has a more restrictive license than the previous versions (AGPLv3 vs. LGPLv2) and due many projects can't use it. Nowadays Fedora uses the old version (5.3.28) and we can't update to newer. Due to many many projects have libdb dependency, we propose few steps to complete removal. First step would mark libdb as deprecated package in Fedora 33. Next steps in Fedora 35 would provide converting tool for existing databases and mark libdb as orphaned.
We would like to remove libdb from Fedora in future, because BerkeleyDB 6.x has a more restrictive license than the previous versions (AGPLv3 vs. LGPLv2) and due many projects can't use it. Nowadays Fedora uses the old version (5.3.28) and we can't update to newer. Due to many projects have libdb dependency, we propose few steps to complete removal. First step would mark libdb as deprecated package in Fedora 33. Next steps in Fedora 35 would provide converting tool for existing databases and mark libdb as orphaned.
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->


Line 90: Line 90:
This change hasn't direct impact onto actual dependencies. Purpose of this change is inform and prepare people to future change which will affect many components.   
This change hasn't direct impact onto actual dependencies. Purpose of this change is inform and prepare people to future change which will affect many components.   


Here is little discussion from Fedora-devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O442UPRAGHD6ZN77GWTARY2VXP24VFBC/#O442UPRAGHD6ZN77GWTARY2VXP24VFBC
Here is short discussion from Fedora-devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O442UPRAGHD6ZN77GWTARY2VXP24VFBC/#O442UPRAGHD6ZN77GWTARY2VXP24VFBC
 
As I mentioned above we would like to remove libdb in the best case in Fedora 35. And time between F33 and F35 we would like to use for discussion about solution, which could transfer existing libdb databases to other and try to find solution for components which supports only libdb.
 


As I mentonied above we would like to remove libdb in the best case in Fedora 35. And time between F33 and F35 we would like to use for discussion and finding solution for porting existing libdb databases to other.
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->


Line 117: Line 119:


== User Experience ==
== User Experience ==
There is no change for users. Package is mark only as deprecated package and behaves as before.
There is no change for users. Package is marked only as deprecated package and behaves as before.




Line 207: Line 209:
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Contingency deadline: N/A (not a System Wide Change)  <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
<!-- Does finishing this feature block the release, or can we ship with the feature in incomplete state? -->
* Blocks release? N/A (not a System Wide Change), Yes/No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks release? No <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Blocks product? product <!-- Applicable for Changes that blocks specific product release/Fedora.next -->
* Blocks product? None <!-- Applicable for Changes that blocks specific product release/Fedora.next -->


== Documentation ==
== Documentation ==
Line 223: Line 225:
-->
-->


[[Category:ChangePageIncomplete]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
Line 230: Line 231:


<!-- Select proper category, default is Self Contained Change -->
<!-- Select proper category, default is Self Contained Change -->
[[Category:SelfContainedChange]]
<!-- [[Category:ChangeReadyForWrangler]] -->
<!-- [[Category:SystemWideChange]] -->

Latest revision as of 17:07, 30 March 2020

Mark libdb as deprecated

Summary

This change should inform maintainers and developers about effort to remove libdb in future.

Owner

Current status

  • Targeted release: Fedora 33
  • Last updated: 2020-03-30
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

We would like to remove libdb from Fedora in future, because BerkeleyDB 6.x has a more restrictive license than the previous versions (AGPLv3 vs. LGPLv2) and due many projects can't use it. Nowadays Fedora uses the old version (5.3.28) and we can't update to newer. Due to many projects have libdb dependency, we propose few steps to complete removal. First step would mark libdb as deprecated package in Fedora 33. Next steps in Fedora 35 would provide converting tool for existing databases and mark libdb as orphaned.

Benefit to Fedora

We would like to have most recent releases of components in Fedora, which are supported by upstreams. But due to licence of BerkeleyDB we need to hold old BerkeleyDB version in Fedora.


Scope

  • Proposal owners:
  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

This change hasn't direct impact onto actual dependencies. Purpose of this change is inform and prepare people to future change which will affect many components.

Here is short discussion from Fedora-devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O442UPRAGHD6ZN77GWTARY2VXP24VFBC/#O442UPRAGHD6ZN77GWTARY2VXP24VFBC

As I mentioned above we would like to remove libdb in the best case in Fedora 35. And time between F33 and F35 we would like to use for discussion about solution, which could transfer existing libdb databases to other and try to find solution for components which supports only libdb.


N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

There is no change for users. Package is marked only as deprecated package and behaves as before.


Dependencies

  • Libdb has many dependencies:
  • 389-ds-base
  • apr-util-bdb
  • bind-sdb
  • bogofilter
  • cld
  • clisp
  • cyrus-sasl-lib
  • dsniff
  • evolution-data-server
  • exim
  • heimdal
  • iproute
  • ipv6calc
  • isync
  • jabberd
  • jigdo
  • jigdo-gui
  • kdesvn
  • libetpan
  • libopendkim
  • libserf
  • lizardfs-master
  • mesos
  • mod_dav_svn
  • mod_perl
  • mod_qos
  • mod_security
  • netatalk
  • nmh
  • nss_updatedb
  • nvi
  • opendkim
  • openldap-servers
  • opensips-db_berkeley
  • opensmtpd
  • pam
  • pam_abl
  • pam_ccreds
  • perdition
  • perl-BDB
  • perl-BerkeleyDB
  • perl-DB_File
  • perl-eperl
  • php-dba
  • pl
  • postfix
  • python3-bsddb3
  • rapidsvn
  • redland
  • reprepro
  • rpm
  • rsvndump
  • sendmail
  • sks
  • spamprobe
  • squid
  • squidGuard
  • subversion
  • tqsllib
  • trustedqsl
  • webalizer
  • xemacs

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? No
  • Blocks product? None

Documentation

N/A (not a System Wide Change)

Release Notes