[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Y2038 - best way forward in Debian?



wzssyqa@gmail.com wrote:
>Steve McIntyre <steve@einval.com> äº?2020å¹´2æ??4æ?¥å?¨äº? ä¸?å??9:15å??é??ï¼?

...

>>  A Follow a similar path to last time (rename library packages). This
>>    will allow us to do partial upgrades, but the cost is that a vast
>>    number of packages will need work to make this happen,
>>    *potentially* building library packages twice to allow us to
>>    continue both 32-bit and 64-bit time_t support forwards for a
>>    while. This effort will be *needed* only for the sake of our 32-bit
>>    ports, but would affect *everybody*.
>>
>>  *** OR ***
>>
>>  B Decide which 32-bit ports we expect to care about by 2038, and
>>    re-bootstrap new versions of those ports *with different
>>    names*. This would allow most of our developers to ignore the
>>    problem here (as 64-bit arches are not affected) and let a smaller
>>    number of people re-bootstrap with new ABIs with 64-bit time_t
>>    embedded. There are some downsides here:

...

>> So, which way should we go? My own personal gut feel matches Arnd's,
>> which would be route B. Some of us already have fair experience with
>> bootstrapping new arches, and we could almost just crank the handle
>> for most of this work.
>
>Is there the option C?
>
>Draft:
>  1. define time64_t
>  2. for data_struct which act as a part of ABI, define a new data_struct64
>  3. for function which act as part of ABI, define a new version func64.
>  4. patch all packages to use time64_t instead of time_t step by step.
>  5. set a time as deadline (2030?), and then treat all packages
>haven't finished
>      the migration as rc-buggy.
>
> Since we have enough time, we can patch all packages in that period.

It's possible, but...

The problem here is that we have many thousands of packages to work
on, glibc up through other libs to all the applications that use
them. It's invasive work, and likely to take a very long time. Since
it's work that would *not* be needed for 64-bit architectures, we're
also likely to see push-back from some upstreams.

2030 is also too late to fix the problem - people are already starting
to see issues in some applications. We want to make a difference soon:
the earlier that we have fixes available, the fewer broken systems
will have to be fixed / removed / replaced later.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.


Reply to: