[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220930125754.GB29905@brightrain.aerifal.cx>
Date: Fri, 30 Sep 2022 08:57:55 -0400
From: Rich Felker <dalias@...c.org>
To: Markus Wichmann <nullplan@....net>
Cc: musl@...ts.openwall.com
Subject: Re: Revisiting LFS64 removal
On Fri, Sep 30, 2022 at 04:44:47AM +0200, Markus Wichmann wrote:
> On Thu, Sep 29, 2022 at 07:07:08PM -0400, Rich Felker wrote:
> > As an alternative, maybe we should consider leaving these but only
> > under explict _LARGEFILE64_SOURCE rather than implicitly via
> > _GNU_SOURCE for at least one release cycle. This would allow makeshift
> > fixing of any builds that break by just adding -D_LARGEFILE64_SOURCE
> > until a proper fix can be applied.
> >
> > Any preference here?
> >
> > Rich
>
> Given that nothing lasts as long as a temporary measure, I'd say it is
That's not a given for musl, quite the opposite. I would expect it to
last at most a release cycle, possibly even to disappear before then
if distros backport the changes to their development branches early
and find and fix everything.
> better to rip the band-aid off in one go rather than two. Besides, any
> breakage ought to be able to be dealt with by a simple replacement,
> right?
It's a simple fix, but the question is how many such simple fixes a
distro might need to make in their packages, and that I don't know.
If they have a trivial mechanical fix of "add something to CFLAGS"
they can do at first, that lets them build a list of affected packages
while quickly getting them all building again, then work out the right
fixes one at a time according to usual triage rather than being
swamped with these taking priority over issues with more depth.
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.
