(Hans reviewed it, so submitting it now.) |
|||
(6 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 | = 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: | [[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/ | * 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: | * FESCo issue: [https://pagure.io/fesco/issue/2510 #2510] | ||
* Tracker bug: | * Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1906540 #1906540] | ||
* Release notes tracker: | * 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 | ||
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
- Name: Benjamin Berg
- Email: bberg@redhat.com
Current status
- Targeted release: Fedora Linux 35
- Last updated: 2021-03-03
- FESCo issue: #2510
- Tracker bug: #1906540
- Release notes tracker: #613
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:
- libusb-compat-0.1 (this *is* the upstream name, see https://github.com/libusb/libusb-compat-0.1)
- libusb1
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 tolibusb-compat-0.1-devel
- Add
Provides: deprecated()
to thelibusb-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. currentlibusb
).
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
.
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- 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)