[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ‘core-updates’ is back!
From: |
Ludovic Courtès |
Subject: |
Re: ‘core-updates’ is back! |
Date: |
Wed, 30 Aug 2017 11:58:03 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Andy Wingo <address@hidden> skribis:
> On Tue 29 Aug 2017 00:01, address@hidden (Ludovic Courtès) writes:
>
>> Yup, I just created a new ‘core-updates’ branch by pushing
>> <https://bugs.gnu.org/27849>. Enjoy!
>>
>> Let’s freeze in one month, say Oct. 1st?
>
> It would be pretty cool if we could fix our O(n^2) problems in search
> paths in this core-updates -- basically whenever you go to create an
> environment, instead of making e.g. VAR=A:B:C:..., for all VARs
> (LIBRARY_PATH, PKG_CONFIG_PATH, etc), instead we make a union directory
> Z containing the union of A, B, C, etc and set VAR=Z. The goal would be
> to fix quadratic run-time lookup costs by replacing it with a
> compile-time computation. This applies to many lookups: PATH, -rpath,
> etc.
A possible alternative solution for ld.so is at
<https://bugs.gnu.org/26048>.
I’m not entirely sure about the idea of creating union directories
everywhere. A problem is that we’d be retaining lots of union
directories, and even if they’re cheap, that could become non-negligible
(for every package we’d have to download/build an extra derivation). It
would also add an extra level of symlinks to go through when one is
debugging things. Also, some tools might not notice that
/abc…/lib/libfoo, /def…/lib/libfoo, and /123…/lib/libfoo actually are
the same thing.
Thoughts?
Ludo’.
Re: ‘core-updates’ is back!, Andy Wingo, 2017/08/29