[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 1 Jul 2019 10:55:30 -0500
From: "A. Wilcox" <awilfox@...lielinux.org>
To: musl@...ts.openwall.com
Subject: Re: Revisiting 64-bit time_t
On 07/01/19 10:41, Rich Felker wrote:
> On Mon, Jul 01, 2019 at 09:50:31AM -0500, A. Wilcox wrote:
>> Adélie rebuilds all packages for every release, and encourages users to
>> use `apk upgrade -al` which will /replace/ all of world for every
>> upgrade, so we'd be very happy with b). Make everything as correct as
>> possible, as quickly as possible, with just a simple upgrade for users
>> (as long as they have no self-compiled software installed).
>>
>> There is already no real "third-party" binary for 32-bit musl computers,
>> so I'm not sure if that's relevant. For glibc binaries, we have gcompat
>> which could easily "shadow" time_t functions with 32-bit versions for as
>> long as glibc binaries continue to have a need.
>
> I think this ignores the reality that a lot of users of any distro
> except Debian pretty much *have to* build some software from source,
> since there's so much more software out there than what you can
> package without contributor bases and infrastructure that size. If you
> break or switch ABI, you invalidate all the existing self-built
> software a user has (unless they static-linked, but that might not be
> an option if the software needs dlopen).
>
> Admittedly distros are not doing a great job with this already. For
> example when I updated Alpine, a bunch of my self-built software
> stopped working because it uninstalled the old boost packages with the
> matching API/ABI. I'm not sure how well Adélie fairs in this regard.
> But in principle it's something that should be able to work. And this
> is a large part of the motivation for why musl committed to stable
> ABIs and of the motivation for musl rather than improving uclibc.
>
> Rich
I specifically did mention "as long as they have no self-compiled
software installed".
At Adélie we have policies that we won't ever sobump things like Boost,
Qt, etc except between major versions. So Adélie 1.x, for all three
years, through 1.9, will always have boost 1.69.0 and Qt 5.9 etc.
Smaller libraries may or may not sobump; we consider addition of APIs
fine as long as no changes or removals were made (so ABI remains
"constant" for existing apps).
Ah yes, ffmpeg, that was the other big one we decided to be careful
about in minor releases.
The only reason we're still bumping right now is because we're still in
beta and haven't released 1.0 yet, so we haven't committed to the 1.0
ABI. And that is primarily because we don't have an installer, though
all the massive CVEs in major packages have been eating up a lot of our
time...
So, if musl were to do this, we wouldn't have the "new musl" available
until Adélie 2.0, which will be 18 months after 1.0 is released. But,
at the time you upgrade 1.x -> 2.0, you are already aware you are
changing ABI for practically every library on the system, so you should
be fully aware of that ahead of time.
Best to you and yours,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
