On 2025-02-17 13:36:05 +0100, Chris Hofstaedtler wrote: > * Michael Stone <mst...@debian.org> [250217 04:19]: > > On Mon, Feb 17, 2025 at 03:11:43AM +0100, Chris Hofstaedtler wrote: > > > The d-devel discussion was in April 2024: > > > https://lists.debian.org/debian-devel/2024/04/msg00406.html > > > Back then would have been a good time to evaluate what changes your > > > package needs, and/or see what breaks, and follow up with such questions. > > > In February 2025 it's a bit late. > > > > There wasn't really a discussion. > > Apparently nobody cared enough.
I rather think that there was misleading information (probably because there was not enough testing yet). In particular, "Thorsten's code introduces new PAM modules to manage the new files, so it should transparently work with most packages." is not true, as you can see. That's why there should have been a transition period. > > > One argument for not keeping stuff that will break in y2038 for > > > trixie is that would make the time_t-64 transition mostly pointless. > > > > No it wouldn't, there can be multiple facilities available. At any rate, IMO > > the transition is pointless *for trixie*, as trixie won't be maintained in > > 2038. The point is to introduce new apis/abis/etc going forward, so that > > future releases (which actually will be used in 2038) will be ready. That > > does not necessitate breaking existing code/functionality. > > I'm onboard with this argument, but then we wouldn't have needed to > do t64 at all. Wasn't this needed for utilities like "date" and most interfaces that use time_t? -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
