Bugzilla – Bug 1221601
libstdc++6: recommends timezone
Last modified: 2024-03-28 11:35:03 UTC
libstdc++6 recommends timezone. Instead of unconditionally recommending timezone that should be left to applications that actually make use of the respective API. Also, the base pattern pulls in timezone anyway. So I'd suggest to remove the recommends from libstdc++6 in order to allow to build containers or portable services without timezone.
How do you figure applications use "the respective API"? Applications built with -std=c++20 expect a conforming implementation to std::chrono. When /usr/share/zoneinfo/tzdata.zi is not present then the standard library can only handle UTC as we choose to not put in a static copy of the database in libstdc++ (you'd lose the size advantage and you'd have to update it for timezone updates). It should have been a Requires (for conformance), but I made it a Recommends so you _can_ ignore it for container installs if you want. But it should be there by default. Maybe instead split 'timezone' so that tzdata.zi is available as a separate sub-package? What's so bad about timezone?
(In reply to Richard Biener from comment #1) > How do you figure applications use "the respective API"? Applications built > with -std=c++20 expect a conforming implementation to std::chrono. Only if an app actually uses std::chrono. ncurses for example doesn't seem to. > When /usr/share/zoneinfo/tzdata.zi is not present then the standard library > can only handle UTC as we choose to not put in a static copy of the > database in libstdc++ (you'd lose the size advantage and you'd have to update > it for timezone updates). Sure, I don't disagree with that. Having timezone stuff central and external is the only sane way to do it. > It should have been a Requires (for conformance), but I made it a Recommends > so you _can_ ignore it for container installs if you want. But it should be > there by default. Needs to be handled by patterns. glibc does not recommend timezone either btw. > Maybe instead split 'timezone' so that tzdata.zi is available as a separate > sub-package? What's so bad about timezone? There's nothing really bad about it. It's just neither necessary nor helpful to recommend timezone at the library level :-) Recommends are a concept that does not really work well for packages that are installed automatically as base OS anyway IMO. MicroOS even installs without recommends, therefore correctly requires timezone via it's pattern. FWIW the reason I noticed because timezone pulls in bash (which might get fixed by https://build.opensuse.org/request/show/1158975).
I see. I'll drop the Requires from gcc14 on then.
This is an autogenerated message for OBS integration: This bug (1221601) was mentioned in https://build.opensuse.org/request/show/1163280 Factory / gcc14