Reduce dependencies on upower
Hi, I saw by chance the submitrequest from Michal from yesterday for libimobiledevice. Maybe this was not a coincident that Olaf asked me to reduce package dependencies for upower on exactly this (libimobiledevice) and libplist packages. The optional libimobiledevice and libplist dependencies on upower seem to serve specific Apple devices (iPad?, ...). A typical use case of upower is to detect low battery or other power related HW events and react accordingly. I would simply remove BuildRequires: to these 2 packages and upower should still compile and work fine on remaining HW. It should still run on Apple HW as well with a reduced feature set. Is there still an rpm/spec conditional flag (OpenSUSE vs SLE vs Micro or whatever) or a multibuild flavor/flag one should use to e.g. enable as much as possible (or special multimedia/desktop features/HW,...)? Any hints and help are welcome, Thomas
Hi Thomas, Thomas Renninger <trenn@suse.de> writes:
Does this: https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto#Dete... help? That should contain all conditionals to distinguish the various openSUSE & SLE distributions. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Freitag, 21. März 2025 13:41:43 Mitteleuropäische Normalzeit Dan Čermák wrote: ...
Thanks! This reminds me to the announcement that with 15.5 / SLE 15 SP5 / Leap 15.5 we want to be binary compatible and all packages are built against the same project, right? So after SLE 15 SP4 it's not possible to distinguish whether a package is built against SLE or OpenSuse or MicroOS and this condition never exists?: %if 0%{?sle_version} > 150400 && !0%{?is_opensuse} Or are there some internally documented flags? This makes a lot of sense to reduce complexity. But if I see this correctly, it's not possible to reduce package dependencies only for Enterprise projects? Thomas
Hi Thomas, Thomas Renninger <trenn@suse.de> writes:
I thought this has been in place starting from Leap 15.3/SLE 15 SP3. But despite that: SLE packages are built in SUSE:SLE-15-SP$N:{GA,Update} and are then copied/inherited into Leap. Leap only packages are built against the openSUSE:Backports projects.
Exactly. The packages are the same binaries, thus it is impossible to distinguish in a SLE & Leap package for which platform it is going to be build. For instance, your above check would afaik always work, because %is_opensuse is false on SLE (which is the base buildroot), but it might be true in the openSUSE:Backports repo.
Or are there some internally documented flags?
I am only aware of https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto
You can make dependencies also conditional on packages that only exist in Leap and those that only exist in SLE, e.g.: --8<---------------cut here---------------start------------->8--- Requires: (SLE_dependency if (product(SL-Micro) or (product(SUSE_SLE) >= 15.5))) Suggests: (Leap_dependency if openSUSE-release) --8<---------------cut here---------------end--------------->8--- Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Dienstag, 25. März 2025 14:34:58 Mitteleuropäische Normalzeit Dan Čermák wrote:
Hi Thomas,
...
Thanks!
Not sure I get this, above is not the correct syntax? That would mean the BuildRequires are fix for all build flavors or in other words: Because there is only one build flavor. But the Requires: could be differed. But this would only work for "soft" Requires where some kind of conditional/ dynamic loading of libraries/plugins at runtime is supported? In my case C libraries seem to be a hard requirement defined at build time. Depending on whether I build against libimobiledevice/libplist, the build system auto-adds the Requires: rpm -qpR upower-1.90.7.13+git.4f1ef04-0.x86_64.rpm ... libimobiledevice-1.0.so.6()(64bit) libplist-2.0.so.4()(64bit) ... Thanks a lot for the details, even it seem not to help in my case. I guess I go for all package dependencies, possibly provide a not used rpm define in case someone wants to remove the dependencies manually. Thanks, Thomas
Hi On 3/26/25 1:00 AM, Thomas Renninger wrote:
That is probably the best bet, the other thing that causes issues is we don't rebuild SLES packages for Leap by default, so even if the spec file did contain conditionals to enable it for openSUSE nothing would happen unless we manually forked the package there so that it rebuilt. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Freitag, 21. März 2025 13:27:21 Mitteleuropäische Normalzeit Thomas Renninger wrote:
According to the relevant source code: https://gitlab.freedesktop.org/upower/upower/-/blob/master/src/linux/up-devi... - It supports iPads and iPods - It reports the charging state (coarse, empty/full, charging, discharging) - It only supports devices connected via USB.
Linux running *on* Apple HW is not affected at all. I think the usage of libimobiledevice by upower is quite questionable, and IMHO out of scope. The main purpose of upower is to provide access to system wide power state and management, i.e. the "chassis" and critical peripherals like input devices. It mostly uses kernel level interfaces (sysfs, udev), and bluez via DBus, i.e. has no dependencies on other third party libraries. It uses privileged interfaces, or a separate process in case of bluetooth/bluez. Removing the libimobiledevice dependency for Leap *and* for Tumbleweed is the right thing to do, unconditionally. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
On Donnerstag, 27. März 2025 15:52:30 Mitteleuropäische Normalzeit Stefan Brüns wrote:
Oha. One might think the devices are always charging when connected via USB... Thanks a lot for your research and tracking this down!
Linux running *on* Apple HW is not affected at all.
I see.
I think the usage of libimobiledevice by upower is quite questionable, and IMHO out of scope.
I agree.
Removing the libimobiledevice dependency for Leap *and* for Tumbleweed is the right thing to do, unconditionally.
I leave a comment and a multibuild flag in the spec file. If someone wants to track when his iPod/iPad is finally fully charged, he can easily self-build his own upower version using the Opensuse Build Service. Thanks, Thomas
Hi Thomas, Thomas Renninger <trenn@suse.de> writes:
Does this: https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto#Dete... help? That should contain all conditionals to distinguish the various openSUSE & SLE distributions. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Freitag, 21. März 2025 13:41:43 Mitteleuropäische Normalzeit Dan Čermák wrote: ...
Thanks! This reminds me to the announcement that with 15.5 / SLE 15 SP5 / Leap 15.5 we want to be binary compatible and all packages are built against the same project, right? So after SLE 15 SP4 it's not possible to distinguish whether a package is built against SLE or OpenSuse or MicroOS and this condition never exists?: %if 0%{?sle_version} > 150400 && !0%{?is_opensuse} Or are there some internally documented flags? This makes a lot of sense to reduce complexity. But if I see this correctly, it's not possible to reduce package dependencies only for Enterprise projects? Thomas
Hi Thomas, Thomas Renninger <trenn@suse.de> writes:
I thought this has been in place starting from Leap 15.3/SLE 15 SP3. But despite that: SLE packages are built in SUSE:SLE-15-SP$N:{GA,Update} and are then copied/inherited into Leap. Leap only packages are built against the openSUSE:Backports projects.
Exactly. The packages are the same binaries, thus it is impossible to distinguish in a SLE & Leap package for which platform it is going to be build. For instance, your above check would afaik always work, because %is_opensuse is false on SLE (which is the base buildroot), but it might be true in the openSUSE:Backports repo.
Or are there some internally documented flags?
I am only aware of https://en.opensuse.org/openSUSE:Build_Service_cross_distribution_howto
You can make dependencies also conditional on packages that only exist in Leap and those that only exist in SLE, e.g.: --8<---------------cut here---------------start------------->8--- Requires: (SLE_dependency if (product(SL-Micro) or (product(SUSE_SLE) >= 15.5))) Suggests: (Leap_dependency if openSUSE-release) --8<---------------cut here---------------end--------------->8--- Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstr. 146 90461 Nürnberg Germany www.suse.com Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Dienstag, 25. März 2025 14:34:58 Mitteleuropäische Normalzeit Dan Čermák wrote:
Hi Thomas,
...
Thanks!
Not sure I get this, above is not the correct syntax? That would mean the BuildRequires are fix for all build flavors or in other words: Because there is only one build flavor. But the Requires: could be differed. But this would only work for "soft" Requires where some kind of conditional/ dynamic loading of libraries/plugins at runtime is supported? In my case C libraries seem to be a hard requirement defined at build time. Depending on whether I build against libimobiledevice/libplist, the build system auto-adds the Requires: rpm -qpR upower-1.90.7.13+git.4f1ef04-0.x86_64.rpm ... libimobiledevice-1.0.so.6()(64bit) libplist-2.0.so.4()(64bit) ... Thanks a lot for the details, even it seem not to help in my case. I guess I go for all package dependencies, possibly provide a not used rpm define in case someone wants to remove the dependencies manually. Thanks, Thomas
Hi On 3/26/25 1:00 AM, Thomas Renninger wrote:
That is probably the best bet, the other thing that causes issues is we don't rebuild SLES packages for Leap by default, so even if the spec file did contain conditionals to enable it for openSUSE nothing would happen unless we manually forked the package there so that it rebuilt. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Freitag, 21. März 2025 13:27:21 Mitteleuropäische Normalzeit Thomas Renninger wrote:
According to the relevant source code: https://gitlab.freedesktop.org/upower/upower/-/blob/master/src/linux/up-devi... - It supports iPads and iPods - It reports the charging state (coarse, empty/full, charging, discharging) - It only supports devices connected via USB.
Linux running *on* Apple HW is not affected at all. I think the usage of libimobiledevice by upower is quite questionable, and IMHO out of scope. The main purpose of upower is to provide access to system wide power state and management, i.e. the "chassis" and critical peripherals like input devices. It mostly uses kernel level interfaces (sysfs, udev), and bluez via DBus, i.e. has no dependencies on other third party libraries. It uses privileged interfaces, or a separate process in case of bluetooth/bluez. Removing the libimobiledevice dependency for Leap *and* for Tumbleweed is the right thing to do, unconditionally. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019
participants (4)
-
Dan Čermák -
Simon Lees -
Stefan Brüns -
Thomas Renninger