https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_deprecated...
== 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`.
== Owner == * Name: [[User:benzea|Benjamin Berg]] * Email: bberg@redhat.com
== 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 * 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.
== Benefit to Fedora ==
* We adhere more closely to the upstream naming scheme for libusb. * We begin sunsetting `libusb-compat` (i.e. current `libusb`).
== Scope == * Proposal owners: Create new `libusb-compat` and `libusb1` packages based on the current ones.
* Other developers: 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`.
* Release engineering: N/A * 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 == [not provided]
== Dependencies == [not provided]
== Contingency Plan ==
Add `Provides: libusb-devel` to `libusb-compat-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)
== Documentation == N/A (not a System Wide Change)
On 11/24/20 9:10 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_deprecated...
== 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`.
Please, don't name packages name-compat. See the guidelines on the topic: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
On Tue, 2020-11-24 at 21:26 +0100, Miro Hrončok wrote:
On 11/24/20 9:10 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_deprecated...
== 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`.
Please, don't name packages name-compat. See the guidelines on the topic: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
The upstream name of the library is "libusb-compat-0.1". So the "compat" part would not be distribution specific in this case.
See https://github.com/libusb/libusb-compat-0.1
Benjamin
On 11/24/20 9:52 PM, Benjamin Berg wrote:
On Tue, 2020-11-24 at 21:26 +0100, Miro Hrončok wrote:
On 11/24/20 9:10 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_deprecated...
== 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`.
Please, don't name packages name-compat. See the guidelines on the topic: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
The upstream name of the library is "libusb-compat-0.1". So the "compat" part would not be distribution specific in this case.
In that case, I guess it is fine, thou a bit confusing. Why not call it libusb-compat-0.1?
On Tue, 2020-11-24 at 21:54 +0100, Miro Hrončok wrote:
On 11/24/20 9:52 PM, Benjamin Berg wrote:
On Tue, 2020-11-24 at 21:26 +0100, Miro Hrončok wrote:
On 11/24/20 9:10 PM, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_deprecated...
== 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`.
Please, don't name packages name-compat. See the guidelines on the topic: https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
The upstream name of the library is "libusb-compat-0.1". So the "compat" part would not be distribution specific in this case.
In that case, I guess it is fine, thou a bit confusing. Why not call it libusb-compat-0.1?
Really, no specific reason. :)
I find it a bit weird with the version as part of the package, but it does indeed seem correct in this case.
Benjamin
On Tue, Nov 24, 2020 at 8:11 PM Ben Cotton bcotton@redhat.com wrote:
Rename `libusb` to `libusb-compat`
It was my recollection that I thought libXXXX-compat package naming was deprecated in favor of libXXXX1 package naming (or libXXXX_1 if the last X was a number) for a .1 soname example.
On 11/24/20 9:10 PM, Ben Cotton wrote:
- We begin sunsetting `libusb-compat` (i.e. current `libusb`).
Consider deprecating it as part of the change:
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packag...
On Tue, 2020-11-24 at 21:30 +0100, Miro Hrončok wrote:
On 11/24/20 9:10 PM, Ben Cotton wrote:
- We begin sunsetting `libusb-compat` (i.e. current `libusb`).
Consider deprecating it as part of the change:
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packag...
True, I was not aware of that possibility. Sounds like a good idea, I'll update the change request to include this.
Benjamin