From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14332 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Revisiting 64-bit time_t Date: Mon, 1 Jul 2019 12:07:44 -0400 Message-ID: <20190701160744.GT1506@brightrain.aerifal.cx> References: <20190628150659.GD1506@brightrain.aerifal.cx> <3424A001-EBF1-412E-B0F4-A7E834966807@adelielinux.org> <20190629162116.GJ1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="9991"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14348-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 01 18:07:59 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hhyqV-0002U3-7d for gllmg-musl@m.gmane.org; Mon, 01 Jul 2019 18:07:59 +0200 Original-Received: (qmail 24317 invoked by uid 550); 1 Jul 2019 16:07:56 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 24298 invoked from network); 1 Jul 2019 16:07:56 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14332 Archived-At: 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