[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190701160744.GT1506@brightrain.aerifal.cx>
Date: Mon, 1 Jul 2019 12:07:44 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Revisiting 64-bit time_t
On Mon, Jul 01, 2019 at 04:41:51PM +0200, Arnd Bergmann wrote:
> c) Keep backwards compatibility in libraries, but convert the
> distro one package at a time.
> Advantage: If done right, users can upgrade over rolling
> releases without ABIs breaking
> Disadvantage: very hard to get right, and much more work
> than the other two.
I'm confused how "convert the distro one package at a time" comes up.
The only packages potentially affected are ones that provide or
consume a non-libc API with time_t or derived types as inputs or
outputs. Such providers and consumers would have to be updated in sync
with each other, but otherwise there should be no constraints about
updating packages. I think this could be implemented with distros'
standard "depends on" and "conflicts with" mechanics.
> unrelated reasons. Debian will probably want c), but might also
> be convinced to replace the existing 32-bit ports with musl based
> ones to avoid the effort and reduce RAM usage at the same
> time ;-)
Replacing libc is like the polar opposite of option (c) here... :-)
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
