* Michael Stone <mst...@debian.org> [250217 04:19]: > On Mon, Feb 17, 2025 at 03:11:43AM +0100, Chris Hofstaedtler wrote: > > * Michael Stone <mst...@debian.org> [250217 02:57]: > > > On Mon, Feb 17, 2025 at 01:32:14AM +0100, Chris Hofstaedtler wrote: > > > > * Vincent Lefevre <vinc...@vinc17.net> [250217 01:20]: > > > > > And what about non-X terminals, such as provided by GNU Screen? > > > [...] > > > > > > > > I can see how they are probably not very interesting. But anyway, > > > > its a question for upstream. > > > > > > No, it's a question for debian. We're releasing a distribution, and we're > > > responsible for the parts and how they go together. Simply shrugging and > > > saying that people are looking for something that isn't interesting is not > > > particularly user-friendly. Can you explain why a phased approach, > > > preserving utmp/wtmp for this release, while deprecating them and > > > introducing an eventual replacement, is not possible *for debian*? > > > > 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. > It's also strange that you didn't contact maintainers of packages > actually using the relevant apis/data. > > 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. > > If relevant parts of the system don't work after y2038, then we also > > wouldn't have needed the time_t-64 transition. Given that it's done, > > it seems logical to follow through. > > Sure, if you actually provide the same functionality without regressions. > That hasn't happened. > > You also haven't answered the question that was asked: "Can you explain why > a phased approach, preserving utmp/wtmp for this release, while deprecating > them and introducing an eventual replacement, is not possible *for debian*?" Feel free to drive that. I'm not. Chris
