guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Starting 'core-updates'?


From: Maxim Cournoyer
Subject: Re: Starting 'core-updates'?
Date: Fri, 31 Jan 2020 14:48:41 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Hello Marius!

Marius Bakke <address@hidden> writes:

> Hello Guix,
>
> The 'core-updates' branch is starting to look pretty good, and I am
> happy to report that it "works for me".  :-)
>
> Some of the big changes include:
>
> * Large parts of Guix can now be cross-compiled, allowing building Guix
>   System for foreign architectures without emulation.
>
> * Python was updated to 3.8.1, and most of the popular packages such as
>   Pytest are at the latest available versions.
>
> * The 'libjpeg' library has been deprecated in favor of 'libjpeg-turbo'.
>
> * 'util-linux' gained a "lib" output, decreasing the closure size of
>   packages that only need the libraries by ~11.5 MiB.
>
> * 'boost' now uses Python 3 by default.
>
> * 'sqlite-with-column-metadata' has been merged with 'sqlite'.
>
> * The quest to remove static libraries from core packages is ongoing.
>   Many packages are a tiny bit smaller for that reason.  On the flip
>   side, the closure size of some packages increased, because they are
>   forced to use the shared library instead of embedding a static copy.
>
> * cmake-build-system's support for cross-compilation is significantly
>   improved.  CMake itself also no longer bundles any of its dependencies
>   (even if they were mostly unused).
>
> * Of course we have the latest versions of core packages such as glibc,
>   make, sed, binutils, etc.
>
> I suggest that we set a "freeze" date shortly after FOSDEM to start
> integrating it.  Are there other branches that should be included?
> Maybe wip-bootstrap or GNOME 3.34?

Congratulations!  I'm using core-updates as well, it seems to be working
pretty well so far as well (except some issue with CPATH causing
compilation warnings from system libraries to be emitted when only the
project's headers should be considered (https://bugs.gnu.org/30756).

I'll be looking at ways to resolve this (going back to
CPLUS_INCLUDE_PATH and C_INCLUDE_PATH without triggering include_next
errors from glibc's headers).

Maxim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]