Hi Ludo, On jeu., 19 janv. 2023 at 15:14, Ludovic Courtès <l...@gnu.org> wrote:
> To me, Emacs is still Emacs, with or without libgccjit. Of course JIT > is an improvement, I don’t deny that, but what I mean is that I still > use Emacs for the very same activities. This is even more true for > polkit, because I don’t interact directly with it. Yeah, there is a trade-off for the maintenance between packages that the most of us want and specialized packages for user’s own needs. This reminds me past discussions about parameterized packages. ;-) Well, for instance the scientific package ’gmsh’ is built full featured – with GUI using ’fltk’. That’s a feature that requires big dependencies; when I mainly use it without GUI. Another example, git-annex is built full featured – able to run the WebApp for instance. That’s a feature that requires a increase of 5%; when I mainly use a very restricted set of Git-Annex features. Another instance, the closure of Guix increases a lot from 1.2 to 1.4. Of course the new version provides many improvements, I do not deny that, but I still use Guix for the very same activities as I am doing since version 1.2. ;-) The tacit policy with Guix packages is that the packages are usually by default “feature maximalist” or specifically named « <foo>-minimal » … > Right, and reportedly, Alpine-based images for things like Python are > smaller than what we do. There’s no cheating here: images are > self-contained. …contrary to Alpine where the packages are usually by default “feature minimalist” or specifically named « <foo>-<with-feature> ». Consider the package Emacs [1] and give a look at the recipe for the package named ’emacs’ [2]. Well, this Alpine package ’emacs’ looks like the Guix package named ’emacs-minimal’, and then Alpine provides these variants (subpackages): emacs-doc emacs-gtk3 emacs-gtk3-nativecomp emacs-nox emacs-x11 emacs-x11-nativecomp 1: <https://pkgs.alpinelinux.org/package/edge/community/x86/emacs> 2: <https://git.alpinelinux.org/aports/tree/community/emacs/APKBUILD> > Maybe a good topic for a sub-group at the Guix Days? :-) Yeah for sure. :-) Although, from my point of view, the main issue is about a policy for package inclusion; I mean there is no secret: light images means images with less features. :-) My personal and biased opinion is that Guix should follow minimalist packages as default packages and provides more variants. But the maintenance cost is not free, IMHO. :-) Cheers, simon