On Thu, Mar 02, 2023 at 02:35:11PM +0100, Miroslav Lichvar wrote: > On Thu, Mar 02, 2023 at 11:57:42AM +0000, Daniel P. Berrangé wrote: > > If any other Fedora maintainer looks after packages that use GNULIB, > > then it is quite likely that they also need to add --disable-year2038 > > to their specfiles to avoid i686 brokenness when talking to any > > non-glibc libraries that use time_t, or exposing a library using time_t > > There are about 150 packages that provide "bundled(gnulib)". About 50 > have "lib" in their name. Just wondering, wouldn't it be less work to > enable 64-bit time_t in the rpm CFLAGS, rebuild everything, and deal > with a potentially smaller number of broken packages with the benefit > of fixing Y2038?
The main reason for i686 continuing to exist at all in Fedora is to facilitate running of externally distributed 32-bit apps (for example wine/steam related). Those apps are all going to be built with 32-bit time_t. IOW if Fedora unconditionally rebuilt its world with 64-bit time_t, it would be killing ABI compatibility with the very things that its i686 RPMs aim to support. AFAICT, Fedora either keeps 32-bit time_t, or kills i686 for good. With regards, Daniel [1] https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval "The remaining use cases of i686 packages (i.e. "multilib") for popular 32-bit applications should continue to work. For example, installing the Steam client (steam.i686), Wine, or other applications that require 32-bit compatibility libraries should still be possible, and not fail due to broken dependencies. " -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
