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. 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.
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*?"
