From Fedora Project Wiki
m (add "may")
 
(7 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


= Rename libusb packages and deprecated old API =
= Rename libusb packages and deprecate old API =


== Summary ==
== Summary ==


Rename `libusb` to `libusb-compat` and `libusbx` to `libusb1`. Do '''not''' provide an automated update path for the old `libusb` build dependency as packages should–and likely can–be updated to use `libusb1`.
Rename `libusb` to `libusb-compat-0.1` and `libusbx` to `libusb1`. Do '''not''' provide an automated update path for the old `libusb` build dependency as packages should–and likely can–be updated to use `libusb1`.


== Owner ==
== Owner ==
Line 23: Line 23:


== Current status ==
== Current status ==
[[Category:ChangePageIncomplete]]
[[Category:ChangeAcceptedF35]]
<!-- 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 32: Line 32:
[[Category:SelfContainedChange]]
[[Category:SelfContainedChange]]


* Targeted release: [[Releases/34| Fedora 34 ]]  
* Targeted release: [[Releases/35| Fedora Linux 35 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Line 41: Line 41:
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
-->
-->
* FESCo issue: <will be assigned by the Wrangler>
* FESCo issue: [https://pagure.io/fesco/issue/2510 #2510]
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1906540 #1906540]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/613 #613]


== Detailed Description ==
== Detailed Description ==
Line 55: Line 55:


To make it clear that "libusb" should not be used anymore and as "libusbx" does not exist anymore, it makes sense to rename the packages as follows:
To make it clear that "libusb" should not be used anymore and as "libusbx" does not exist anymore, it makes sense to rename the packages as follows:
* libusb-compat
* libusb-compat-0.1 (this *is* the upstream name, see https://github.com/libusb/libusb-compat-0.1)
* libusb1
* libusb1


In order to ensure that no package is depending on the old `libusb` (i.e. `libusb-compat`) without a good reason, the plan is to '''not''' add the corresponding `Provides:` line for the `libusb-compat-devel` rename.
There should be no/few users left for `libusb-compat-0.1`, but currently some packages are incorrectly using `libusb`. As such, the idea is to:
* '''not''' add the corresponding `Provides:` line for the rename to `libusb-compat-0.1-devel`
* Add `Provides:  deprecated()` to the `libusb-compat-0.1` package


== Feedback ==
== Feedback ==
Line 67: Line 69:


* We adhere more closely to the upstream naming scheme for libusb.
* We adhere more closely to the upstream naming scheme for libusb.
* We begin sunsetting `libusb-compat` (i.e. current `libusb`).
* We begin sunsetting `libusb-compat-0.1` (i.e. current `libusb`).


<!-- 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 100: Line 102:
* Proposal owners:
* Proposal owners:


Create new `libusb-compat` and `libusb1` packages based on the current ones.
Create new `libusb-compat-0.1` and `libusb1` packages based on the current ones.


* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->


Review any package that uses `BuildRequires: libusb-devel`. Many of them will be able to switch to `libusb1-devel` but some may still require the compatibility layer, i.e. `libusb-compat-devel`.
Review any package that uses `BuildRequires: libusb-devel`. Many of them will be able to switch to `libusb1-devel` but some may still require the compatibility layer, i.e. `libusb-compat-0.1-devel`.


* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Release engineering: [https://pagure.io/releng/issues #Releng issue number] (a check of an impact with Release Engineering is needed) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
Line 158: Line 160:
== Contingency Plan ==
== Contingency Plan ==


Add `Provides: libusb-devel` to `libusb-compat-devel` if too many packages are not updated.
Add `Provides: libusb-devel` to `libusb-compat-0.1-devel` if too many packages are not updated.


<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan?  This might be as simple as "Revert the shipped configuration".  Or it might not (e.g. rebuilding a number of dependent packages).  If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy.  -->

Latest revision as of 20:25, 3 March 2021


Rename libusb packages and deprecate old API

Summary

Rename libusb to libusb-compat-0.1 and libusbx to libusb1. Do not provide an automated update path for the old libusb build dependency as packages should–and likely can–be updated to use libusb1.

Owner

Current status

Detailed Description

Currently we have two related packages:

  • libusb: Containing a compatibility layer of the 0.1 API for libusb 1.0
  • libusbx: Containing the libusb 1.0 API, where the name "libusbx" derives from a fork that existed for a while

To make it clear that "libusb" should not be used anymore and as "libusbx" does not exist anymore, it makes sense to rename the packages as follows:

There should be no/few users left for libusb-compat-0.1, but currently some packages are incorrectly using libusb. As such, the idea is to:

  • not add the corresponding Provides: line for the rename to libusb-compat-0.1-devel
  • Add Provides: deprecated() to the libusb-compat-0.1 package

Feedback

Benefit to Fedora

  • We adhere more closely to the upstream naming scheme for libusb.
  • We begin sunsetting libusb-compat-0.1 (i.e. current libusb).


Scope

  • Proposal owners:

Create new libusb-compat-0.1 and libusb1 packages based on the current ones.

  • Other developers: N/A (not a System Wide Change)

Review any package that uses BuildRequires: libusb-devel. Many of them will be able to switch to libusb1-devel but some may still require the compatibility layer, i.e. libusb-compat-0.1-devel.

  • Policies and guidelines: N/A (not needed for this change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with Objectives: N/A

Upgrade/compatibility impact

No impact is expected.

How To Test

No further testing is needed.

User Experience

Dependencies

Contingency Plan

Add Provides: libusb-devel to libusb-compat-0.1-devel if too many packages are not updated.

  • 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? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Rename_libusb_packages_and_deprecated_old_api&oldid=606768"