Re: 64-bit time_t transition for 32-bit archs: a proposal
Simon McVittie dijo [Tue, Jun 06, 2023 at 11:45:26AM +0100]:
> On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> > Judging from the conversation, killing i386 quite obviously is desired
> > by some participants, but evidently not by all. How quickly we want to
> > kill it is not obvious to me.
>
> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:
>
> 1. i386 as a fully-featured architecture that you can run independently
> on 32-bit x86 systems from roughly the 2000-2010 era
>
> 2. i386 as a multiarch foreign architecture to run legacy binaries on
> modern x86_64 systems
> 2a. legacy native Linux i386 binaries
> 2b. legacy Windows i386 binaries via Wine (which requires a somewhat
> complete i386 Linux library stack)
> (...)
I completely agree with your analysis here, and I agree we should
strive to keep 2a and 2b covered, as they are (and they will be, every
time by a bigger margin) by far more common and productive than 1. I
agree with your assessment that date woes will be minor for the i386
user than incompatibility woes going forward; there is the possible
case of people running I-don't-know-which proprietay productivity tool
provided as a binary that cannot be convinced of a 64-bit time_t that
will receive errors when the timeocalypse approaches, but I guess the
gaming use cases will be much more frequent than that; even though
your vision might be somewhat skewed by the fact that you work in
Steam, it makes complete sense.
Of course, given our i386 users would be running (>10 years for now) a
Debian architecture used mostly for compatibility with old non-free
binaries, we'd have to think whether it makes sense to provide a full
Debian experience (i.e. you don't want i386 users to have a PostgreSQL
with a known-borked time implementation storing important information
in it -- and of course, this is only the first of too many examples
that comes to my mind, but won the race to get to my fingers 😉)
But anyway, back to what matters here: I support Helmut's idea. I have
long thought we fear the GR process too much, and we should excercise
it more. Not every GR has to be a flamefest. Having a clear statement
of what is being voted on, and the possible consequences on each of
the options, can lead to a civil, useful way to measure the opinion of
project members interested in the subject.
Right now, I imagine a ballot similar to:
The future of i386 in Debian from Trixie onwards
A. Drop support of i386 completely
B. Keep support of i386 as a multiarch-foreign arch, with 32-bit time_t
C. Keep support of i386 as a multiarch-foreign arch, with 64-bit time_t
D. Commit to supporting i386 as a full-featured arch, with 32-bit time_t
E. Commit to supporting i386 as a full-featured arch, with 64-bit time_t
F. Further discussion
I know this woul conflate two decisions in one ballot, but arguably
they are part of the same issue. I do not feel qualified to draft the
full vote, as I have not followed the discussion as closely as I'd
like to and I'm not directly affected anyway, but would be very happy
to second it.
FWIW, I believe the only real danger in having non-controversial GRs
would be that a vote does not reach quorum (48 voters in the last GR),
but I don't believe it is a real danger to worry about; in any case,
failure to reach quorum would mean the project does not _mandate_ a
decision, but it can be anyway implemented by porters / RT.
Reply to: