After upgrading hyprutils from 0.2.6 to 0.3.0. There are some reverse dependencies with preserved libs: !!! existing preserved libs: >>> package: gui-libs/hyprutils-0.3.0 * - /usr/lib64/libhyprutils.so.0.2.6 * - /usr/lib64/libhyprutils.so.1 * used by /usr/bin/Hyprland (gui-wm/hyprland-9999) * used by /usr/bin/hyprctl (gui-wm/hyprland-9999) * used by /usr/bin/hypridle (gui-apps/hypridle-9999) * used by /usr/bin/hyprlock (gui-apps/hyprlock-0.5.0) * used by /usr/bin/hyprpaper (gui-apps/hyprpaper-0.7.1) * used by /usr/bin/hyprpm (gui-wm/hyprland-9999) * used by /usr/bin/hyprsunset (gui-apps/hyprsunset-9999) * used by /usr/bin/hyprsysteminfo (gui-apps/hyprsysteminfo-0.1.0) * used by /usr/lib64/libaquamarine.so.0.5.1 (gui-libs/aquamarine-9999) * used by /usr/lib64/libhyprgraphics.so.0.1.1 (gui-libs/hyprgraphics-9999) Please introduce a subslot and make use of it in the reverse dependencies. https://devmanual.gentoo.org/general-concepts/slotting/ Reproducible: Always
FYI this issue has been fixed upstream in 0.1.11 I backported the patch in 0.1.10-r1
hi Julien Roy, I saw you using SLOT="0/$(ver_cut 1-2)" in PR 39866, it's too fine control which might introducing some unnecessary rebuild I feel it's more proper to extract the so library version as the subslot, for example package 0.2.6, the lib is /usr/lib64/libhyprutils.so.1, so we get "1" here.. for 0.3.0, we got 2 what do you think?
(In reply to Yixun Lan from comment #2) > hi Julien Roy, > > I saw you using SLOT="0/$(ver_cut 1-2)" in PR 39866, it's too fine control > which might introducing some unnecessary rebuild > > I feel it's more proper to extract the so library version as the subslot, > for example package 0.2.6, the lib is /usr/lib64/libhyprutils.so.1, so we > get "1" here.. for 0.3.0, we got 2 > > what do you think? the assumption is that hyprutils upstream should take care of the library version, increase it once there is API changes..
(In reply to Yixun Lan from comment #3) > (In reply to Yixun Lan from comment #2) > > hi Julien Roy, > > > > I saw you using SLOT="0/$(ver_cut 1-2)" in PR 39866, it's too fine control > > which might introducing some unnecessary rebuild > > > > I feel it's more proper to extract the so library version as the subslot, > > for example package 0.2.6, the lib is /usr/lib64/libhyprutils.so.1, so we > > get "1" here.. for 0.3.0, we got 2 > > > > what do you think? > > the assumption is that hyprutils upstream should take care of the library > version, increase it once there is API changes.. Hi Yixuan, In theory, upstream will only increase the minor version on ABI/API breaking changes, so using $(ver_cut 1-2) will handle rebuilds only when necessary, without needing manual modifications to the ebuild. For doing it the way you suggest, it means putting the .so version manually in the sub-slot variable? I fear that doing it this way may result in me (or other maintainers) forgetting to increase the sub-slot version in the ebuild. What do you think?
(In reply to Julien Roy from comment #1) > FYI this issue has been fixed upstream in 0.1.11 > I backported the patch in 0.1.10-r1 Posted this message on the wrong bug, please disregard this comment :)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3ab202e8f4c13f3993e1e843860dbcb2ea05a5cd commit 3ab202e8f4c13f3993e1e843860dbcb2ea05a5cd Author: Julien Roy <julien@jroy.ca> AuthorDate: 2024-12-27 15:58:23 +0000 Commit: Yixun Lan <dlan@gentoo.org> CommitDate: 2024-12-29 00:00:11 +0000 gui-libs/hyprutils: introduce subslot Closes: https://bugs.gentoo.org/947008 Signed-off-by: Julien Roy <julien@jroy.ca> Signed-off-by: Yixun Lan <dlan@gentoo.org> gui-libs/hyprutils/hyprutils-0.3.0-r1.ebuild | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+)
