On Sat, Dec 02, 2023 at 02:58:00PM +0100, John Paul Adrian Glaubitz wrote: > > Maybe instead of duplicating this, debhelper can access it?
> I agree with Helmut's suggestion. debhelper should be able to deal with > 32-bit architectures that already support 64-bit time_t. > If we ignore these, we could run into issues with potential new 32-bit ports > such as ARC. debhelper handling of 64-bit time_t is limited to deciding whether or not to emit Provides: for the library package name without the 't64' tag. It is only of value for maintaining dependency compatibility with existing runtime library packages built before the transition. The impact for *NEW* architectures is therefore moot, regardless. For similar reasons, I expect it to be low impact for the other already-defined architectures here as well. If any of these named architectures have public stable archives at all, it is nevertheless exceedingly unlikely that there are third-party packages built *against* such an archive that anyone cares about maintaining binary compatibility with. So while this bug is 100% technically correct, I can't see that there is any practical impact at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ [email protected] [email protected]
signature.asc
Description: PGP signature
