From Fedora Project Wiki
No edit summary
(Add trackers)
 
(7 intermediate revisions by 3 users not shown)
Line 2: Line 2:


== Summary ==
== Summary ==
This change should inform maintainers and developers about effort to remove libdb in future.  
This change should inform maintainers and developers about effort to remove libdb (with all subpackages) in future.  
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release.  
Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
Note that motivation for the change should be in the Benefit to Fedora section below, and this part should answer the question "What?" rather than "Why?". -->
Line 32: Line 32:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* FESCo ticket: [https://pagure.io/fesco/issue/2379 #2379]
* Release notes tracker: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1834842 #1834842]
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/505 #505]


== Detailed Description ==
== Detailed Description ==
Line 41: Line 42:
== Benefit to Fedora ==
== 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.
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.
 
<!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
<!-- What is the benefit to the distribution?  Will the software we generate be improved? How will the process of creating Fedora releases be improved?
    
    
Line 72: Line 72:
== Scope ==
== Scope ==
* Proposal owners: Not needed for this change - only deprecation
* Proposal owners: Not needed for this change - only deprecation
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


* Other developers:
* Other developers: Developers should prepare own projects(scripts, programs, packages, ...) for the next change and for the complete libdb removal.
Developers should prepare own projects(scripts, programs, packages, ...) for the next change and for the complete libdb removal.
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


Line 92: 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 short discussion from Fedora-devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O442UPRAGHD6ZN77GWTARY2VXP24VFBC/#O442UPRAGHD6ZN77GWTARY2VXP24VFBC
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/O442UPRAGHD6ZN77GWTARY2VXP24VFBC/#O442UPRAGHD6ZN77GWTARY2VXP24VFBC Here] is short discussion from Fedora-devel list.


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 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.
<!-- 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? -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  


Line 117: Line 110:


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
== User Experience ==
== User Experience ==
There is no change for users. Package is marked 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.
<!-- If this change proposal is noticeable by users, how will their experiences change as a result?
<!-- If this change proposal is noticeable by users, how will their experiences change as a result?


Line 132: Line 122:
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
  - Green has been scientifically proven to be the most relaxing color. The move to a default background color of green with green text will result in Fedora users being the most relaxed users of any operating system.
-->
-->
== Dependencies ==
== Dependencies ==
*Libdb has many dependencies:
*Libdb has many dependencies:
Line 154: Line 143:
*kdesvn
*kdesvn
*libetpan
*libetpan
*libopendkim
*libopendkim [https://github.com/trusteddomainproject/OpenDKIM/issues/71 Upstream issue]
*libserf
*libserf
*lizardfs-master
*lizardfs-master
Line 166: Line 155:
*nss_updatedb
*nss_updatedb
*nvi
*nvi
*opendkim
*opendkim [https://github.com/trusteddomainproject/OpenDKIM/issues/71 Upstream issue]
*openldap-servers
*openldap-servers
*opensips-db_berkeley
*opensips-db_berkeley
Line 198: Line 187:
*xemacs
*xemacs
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->
<!-- What other packages (RPMs) depend on this package?  Are there changes outside the developers' control on which completion of this change depends?  In other words, completion of another change owned by someone else and might cause you to not be able to finish on time or that you would need to coordinate?  Other upstream projects like the kernel (if this is not a kernel change)? -->


== Contingency Plan ==
== Contingency Plan ==
Line 215: Line 203:
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
There is no upstream documentation, but [[User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora|here]] is a list of dependencies with some useful comments and [[User:Pkubat/BerkeleyDB_alternatives|here]] some possible alternatives.
There is no upstream documentation, but [[User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora|here]] is a list of dependencies with some useful comments and [[User:Pkubat/BerkeleyDB_alternatives|here]] some possible alternatives.


== Release Notes ==
== Release Notes ==
Line 224: Line 211:
-->
-->


[[Category:ChangeReadyForWrangler]]
[[Category:ChangeAcceptedF33]]
<!-- 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 -->

Latest revision as of 14:12, 12 May 2020

Mark libdb as deprecated

Summary

This change should inform maintainers and developers about effort to remove libdb (with all subpackages) in future.

Owner

Current status

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: Not needed for this change - only deprecation
  • Other developers: Developers should prepare own projects(scripts, programs, packages, ...) for the next change and for the complete libdb removal.
  • Policies and guidelines: Not needed for this change - only deprecation
  • Trademark approval: Not needed for this change - only deprecation

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.

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.

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 Upstream issue
  • libserf
  • lizardfs-master
  • mesos
  • mod_dav_svn
  • mod_perl
  • mod_qos
  • mod_security
  • netatalk
  • nmh
  • nss_updatedb
  • nvi
  • opendkim Upstream issue
  • 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

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

There is no upstream documentation, but here is a list of dependencies with some useful comments and here some possible alternatives.

Release Notes