Hi Steve,
On Tue, Jun 06, 2023 at 12:45:42PM -0700, Steve Langasek wrote:
> I have a different read on the consensus here. While there has been a lot
> of discussion about whether to continue supporting i386 as a host arch,
> almost everyone participating in the thread who said they want this is not a
> voting member of Debian. The lone exception that I can recall from the
> thread was Guillem, who, as dpkg maintainer, is certainly a stakeholder in
> this decision (and since we don't really have an "i386 porting team",
> probably the most important individual stakeholder).
I concur. Given Simon's analysis and the replies even when combined with
earlier messages, I now see significantly more voices for the opinion:
i386 primarily exists for running legacy binaries and binary
compatibility with legacy executables is more important than correct
representation of time beyond 2038.
I'm inclined to call this consensus now and therefore ask those that do
not agree with it to reply here - even if your reply is only stating
that you disagree. As such, I think we can skip the GR part unless we
get (5?) disagreeing replies here.
Guillem, I understand that you see things differently, but that now
seems like a minority opinion to me. Are you ok with moving forward with
the proposed consensus-or-GR process? My understanding is that you
disagree with the opinion stated above, correct?
While Gunar also raises the question of whether i386 should continue as
a full or partial architecture, I do not think this is influences the
time_t bits decision. The default for now is keeping it as a full
architecture and the time_t migration does not benefit from changing
this. Therefore, I propose restricting the potential GR to the binary
way that Simon presented.
> Since my read is that Guillem was in the "rough" of "rough consensus", I
> asked him directly how we should move forward on a decision. A GR is one
> option, and I think it's definitely a better option than going through the
> TC: while there is a decision to be made here about a "technical" detail of
> what dpkg-buildflags will do, you're right to point out that it's really a
> decision about what we want to support as a project.
Yes, dragging this question on is - as usual - the worst of options.
> Hmm, I don't share this particular concern. PIE is a change to compiler
> behavior. 32-bit time_t is a change to defines that modify types (and
> prototypes) used in header files. Maintaining a compiler is hard,
> maintaining a library ABI is "easy" - glibc has avoided breaking ABI for 25
> years so far.
The similarity is that both is changing flags. I expect that some
packages will need special handling for time64 and some of them may fail
to handle i386 correctly when they only match on bits. If we can get
maintainers to match on the resulting dpkg-buildflags rather than bits,
that's a non-issue probably.
> I am not keen to try to drive a GR on this, but if you raised one I'm likely
> to second it.
Cool. From my point of view consensus is better than GR is better than
deferring or invoking the CTTE. Hope consensus works out. :)
Helmut
