From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14345 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Arnd Bergmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: Revisiting 64-bit time_t Date: Tue, 2 Jul 2019 11:35:25 +0200 Message-ID: References: <20190628150659.GD1506@brightrain.aerifal.cx> <3424A001-EBF1-412E-B0F4-A7E834966807@adelielinux.org> <20190629162116.GJ1506@brightrain.aerifal.cx> <20190701160744.GT1506@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="262048"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-14361-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jul 02 11:35:57 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 1hiFCf-0015za-Eg for gllmg-musl@m.gmane.org; Tue, 02 Jul 2019 11:35:57 +0200 Original-Received: (qmail 3246 invoked by uid 550); 2 Jul 2019 09:35:55 -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 3226 invoked from network); 2 Jul 2019 09:35:54 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=Hb+/mVR3voZwUxutke8Y4l7BhKEHAFkSJh0S4nsP7j4=; b=azXkCDHF+Xc8anG9aNDkhQQdMVog6FBj0eD8IWAKNR8UJ+9qW7zEk5IrMpm2M8NVQU R3TpD18UEFexdxzsguK7KPay3Sz7x7mmKX1MELFgwp9r2PvMEYSeNxGSsnHJdz6GaWgQ M/AkBY6ekiqmOLsWkho8cOTxoiFBkpPRdmDKJ4EvYmKtU5SEAo73bgvU7B4PirIoGoVG EZihFJIfT+lXlUTWbRtPn6zWsfXxS5DhImV81nslT+VoZqpdm56q+c4jJGl/CL+W+oPA f1b6Nc4zjtqJJZLDUl1sjSQaRPc5dsexafMTbJB2sVhqJNW4A7BpIE2rrQaunQ79tLTs QCyg== X-Gm-Message-State: APjAAAVpypt7XNAJZt1ome5lzk2CCME+j8paV2MUsmm+eXflS/Dmu2+o rv6HfJnw6l4kUg3LygjufGr4J389rryZZo0gjp/oLDfa X-Google-Smtp-Source: APXvYqzw9A1emSsaCJ8b7OJ9UWrkhyTbUok12GBj8iVZynAFnHYwSexjHCdw05DwHcZljjI1UDI1C4Zyx1cbAPxcUeU= X-Received: by 2002:aed:33a4:: with SMTP id v33mr23966782qtd.18.1562060142176; Tue, 02 Jul 2019 02:35:42 -0700 (PDT) In-Reply-To: <20190701160744.GT1506@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:14345 Archived-At: On Mon, Jul 1, 2019 at 6:08 PM Rich Felker wrote: > > 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. The difference to b) would be that one allows single package updates at all, within the constraints of the distro dependency system. Actually figuring the dependencies and documenting them is most of the work here. > > 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... :-) Correct, this would basically put debian-i386 and debian-armhf into category a), and create a new debian-musl-386 and debian-musl-armhf that starts out with time64, and have these maintained in parallel for as long as there is demand for both. One reason why this may be interesting is that it reduces the impact on the 64-bit Debian ports, which don't have to go through the pain of a rebuild with new package versions and dependencies when the actual ABI never changes for them. It depends a bit on what approach Debian chooses for upgrading some of the key packages, but if they determine that e.g. libcurl, libssl, libgtk, libpng and libreadline would all need a new soname for their library because of unfixable ABI incompatibility, *and* they want to keep the soname the same between 32 and 64 bit at all cost, then a new incompatible distro port can be the easier way out. (it's clearly too early to know what it will take to rebuild 32-bit debian fro time64, but we an think about the possible alternatives). Side question for this: do you have an estimate of the potential RAM saving when comparing glibc with musl builds of the same software? Arnd