Re: cannot boot after installation on VPS (via rescue system)

[Giovanni Biscuolo]

Hi Wojtek!

Wojtek Kosior  writes:

>> --8<---cut here---start->8---
>> 
>> Scanning for Btrfs filesystems
>> ice-9/boot9.scm:1685:16: In procedure raise-exception:
>> In procedure mount: No such file or directory
>> GRUB loading...
>> Entering a new prompt.  Type ',bt' for a backtrace or ',q' to continue.
>> [...]
>> scheme@(guile-user)> ,bt
>> In gnu/build/linux-boot.scm:
>> 637:8  3 (_)
>> 435:8  2 (mount-root-filesystem "/dev/sda3" "btrfs" # _ #:flags ?)
>> In unknown file:
>>1 (mount "/dev/sda3" "/root" "btrfs" 0 "compress=zstd")
>> In ice-9/boot9.scm:
>>   1685:16: 0 (raise-exception _ #:continuable? _)
>> 
>> --8<---cut here---end--->8---
>
> Maybe the device file is called different from /dev/sda3?

Maybe, but I also tried using UUID (the usual method I use) and label,
both failing... I'll investigate

> On one VPS of mine (which also happens to have Guix installed via
> rescue mode) the root is mounted from /dev/vda1.

Out of curiosity: what's the hoster, please?

>> In particular, I don't understand why the boot script is trying to mount
>> the root filesystem at "/root" and not at "/" as it should: am I missing
>> something?
>
> Linux-based systems typically start with initrd filesystem mounted at
> /.  They then mount the real root at some subdirectory of / and use
> either chroot or pivot-root system call to make the processes see it as
> if it were mounted at / in the first place.

Yes! Thank you for your explanation: I checked gnu/build/linux-boot.scm
and it's just as you pointed out; I simply overlooked the error was in
the "initrd phase"... and now I'm starting to barely understand what's
happening

> I'm not an expert in early boot process so please forgive me any
> mistakes I might have made in this explanation :)

No mistakes :-D

Thank you for your help! Gio'

-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: cannot boot after installation on VPS (via rescue system)

[Giovanni Biscuolo]

Hi Joshua!

jbra...@dismail.de writes:

[...]

>> Now I'm trying to use it on two VPS from two different vendors, booted
>> in rescue mode, but after the installation (via bootstrap-guix.sh) when
>> I reboot the VPS I get the usual grub menu but the boot process suddenly
>> fails with this error (manually copied from web console, sorry for
>> possible typos):
>
> I just logged into my linode server...your script defaults to a btrfs
> filesystem right?

Right, and now that you pointed to that I realized that may be not a
good idea for a QEMU virtual machine [1]: I'll switch to ext4 to be sure

> When I tried to add an additional disk in linode just now, the only
> supported filesystem was ext4.  Does linode support btrfs?

I'm not on Linode, I'm working on OVH and Hetzner VPSs

Anyway I don't think that the boot issue is connected with BTRFS, but
I'll investigate!

Thank you! Gio'

[...]

[1] I don't know the host filesystem but if it's BTRFS, placing a COW
(qcow2) filesystem on top of another COW have a very bad performance,
see
https://www.qemu.org/docs/master/system/qemu-block-drivers.html#cmdoption-qcow2-arg-nocow


-- 
Giovanni Biscuolo

Xelera IT Infrastructures


signature.asc
Description: PGP signature

Re: Guix Days: Patch flow discussion

[Development of GNU Guix and the GNU System distribution.]

Hi Vagrant,

On Sun, Feb 11 2024, Vagrant Cascadian wrote:

> Are there other downsides to allowing a multiple patches in a single
> email?

Is it perhaps more difficult to apply those patches?

Kind regards
Felix

Re: cannot boot after installation on VPS (via rescue system)

[Development of GNU Guix and the GNU System distribution.]

> --8<---cut here---start->8---
> 
> Scanning for Btrfs filesystems
> ice-9/boot9.scm:1685:16: In procedure raise-exception:
> In procedure mount: No such file or directory
> GRUB loading...
> Entering a new prompt.  Type ',bt' for a backtrace or ',q' to continue.
> [...]
> scheme@(guile-user)> ,bt
> In gnu/build/linux-boot.scm:
> 637:8  3 (_)
> 435:8  2 (mount-root-filesystem "/dev/sda3" "btrfs" # _ #:flags ?)
> In unknown file:
>1 (mount "/dev/sda3" "/root" "btrfs" 0 "compress=zstd")
> In ice-9/boot9.scm:
>   1685:16: 0 (raise-exception _ #:continuable? _)
> 
> --8<---cut here---end--->8---

Maybe the device file is called different from /dev/sda3?  On one VPS of
mine (which also happens to have Guix installed via rescue mode) the
root is mounted from /dev/vda1.

> In particular, I don't understand why the boot script is trying to mount
> the root filesystem at "/root" and not at "/" as it should: am I missing
> something?

Linux-based systems typically start with initrd filesystem mounted at
/.  They then mount the real root at some subdirectory of / and use
either chroot or pivot-root system call to make the processes see it as
if it were mounted at / in the first place.

I'm not an expert in early boot process so please forgive me any
mistakes I might have made in this explanation :)

Best,
Wojtek


-- (sig_start)
website: https://koszko.org/koszko.html
fingerprint: E972 7060 E3C5 637C 8A4F  4B42 4BC5 221C 5A79 FD1A
follow me on Fediverse: https://friendica.me/profile/koszko/profile

♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ==
✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8=
-- (sig_end)


On Wed, 21 Feb 2024 10:54:16 +0100 Giovanni Biscuolo  wrote:

> From: Giovanni Biscuolo 
> To: guix-devel@gnu.org
> Subject: cannot boot after installation on VPS (via rescue system)
> Date: Wed, 21 Feb 2024 10:54:16 +0100
> Sender: guix-devel-bounces+koszko=koszko@gnu.org
> Organization: Xelera.eu
> 
> Hello,
> 
> following the good guidelines from (info "(guix-cookbook) Running Guix
> on a Kimsufi Server") and (info "(guix-cookbook) Running Guix on a
> Linode Server") I'm developing a shell script to automate the "manual"
> installation of Guix on bare metal and VPS, you can find it attached to
> this email as bootstrap-guix.sh or at this git repo URL:
> https://gitlab.com/softwareworkers/swws/-/blob/master/infrastructure/hosts/cornouiller/bootstrap-guix.sh?ref_type=heads
> 
> 
> [bootstrap-guix.sh  text/x-sh (11954 bytes)] 
> 
> 
> The main purpose of the script is to allow me to install Guix on
> machines (bare metal or virtual) hosted by vendors who do not offer Guix
> in their OS installation options, since almost all vendors provides a
> rescue system that can be used to "manually" set up the environment,
> partition the target disk and lastly "guix system init..."
> 
> I've extensively tested the script locally (on bare metal and QEMU VMs),
> both booting the machines via grml [1] and Guix install image and it
> works as expected; I've also used it to install Guix on some bare metal.
> 
> Now I'm trying to use it on two VPS from two different vendors, booted
> in rescue mode, but after the installation (via bootstrap-guix.sh) when
> I reboot the VPS I get the usual grub menu but the boot process suddenly
> fails with this error (manually copied from web console, sorry for
> possible typos):
> 
> --8<---cut here---start->8---
> 
> Scanning for Btrfs filesystems
> ice-9/boot9.scm:1685:16: In procedure raise-exception:
> In procedure mount: No such file or directory
> GRUB loading...
> Entering a new prompt.  Type ',bt' for a backtrace or ',q' to continue.
> [...]
> scheme@(guile-user)> ,bt
> In gnu/build/linux-boot.scm:
> 637:8  3 (_)
> 435:8  2 (mount-root-filesystem "/dev/sda3" "btrfs" # _ #:flags ?)
> In unknown file:
>1 (mount "/dev/sda3" "/root" "btrfs" 0 "compress=zstd")
> In ice-9/boot9.scm:
>   1685:16: 0 (raise-exception _ #:continuable? _)
> 
> --8<---cut here---end--->8---
> 
> In particular, I don't understand why the boot script is trying to mount
> the root filesystem at "/root" and not at "/" as it should: am I missing
> something?
> 
> I suspect that the issue depends on how the rescue system root is
> mounted (overlay filesystem) but I'm not sure; I cannot find a solution.
> 
> I'm also attaching:
> 
> - bootstrap-config.scm: automatically generated by the script and used
> by "guix system init..."
> 
> 
> [bootstrap-config.scm  text/x-script.guile (2097 bytes)] 
> 
> 
> - bootstrap-mount-points.txt: automatically collected during installation
> 
> 
> [bootstrap-mount-points.txt  text/plain (2833 bytes)] 
> 
> 
> You can find all the files also here:
> 

Re: Feedback of the GNU Guix manual

[Matt]

  On Wed, 21 Feb 2024 18:20:19 +0100  Maxim Cournoyer  wrote --- 

 > Thanks for the follow-up.

Thank you!  Seems like we were looking at it at about the same time :)

 > Like Josselin, I prefer to keep the mention that the tarball archive
 > includes the transitive dependencies of Guix (it's explicit; "archived
 > binaries" is a bit vague to my taste).

I tried to address that in the diff I wrote up before I saw your message.  I 
agree, "archived binaries" is awkward.  I changed it in my update.

 > I've pushed your adjusted suggestions with commit ec9c8b0c1a.
 
Cool.  I'll work on the next item in the list.  Please let me know if there's 
something more regarding this item based on the v2 update.

Re: [Cuirass] JavaScript work

[Maxim Cournoyer]

Hi,

Ricardo Wurmus  writes:

> Hi,
>
> I noticed that Cuirass bundles minified JavaScript.  I’ve started a new
> branch that replaces the minified JavaScript with readable source code
> and minifies the files as part of the build.
>
> I also tried to remove the need for jQuery, at least in our own
> JavaScript code.  (Datatables.js still uses jQuery.)
>
> Eventually, I’d like to remove Bootstrap (both CSS and JS) all together
> and switch to Pico.css for conventional default styles without the need
> for bootstrap classes everywhere.  I’d like to remove JS for thing that
> HTML+CSS can do just fine.
>
> (Pico is also used in mumi.)
>
> What do you think?

Sounds good to me.  Like Janneke, I also think we can do without JS
obfuscation (minification).

-- 
Thanks,
Maxim

Re: Feedback of the GNU Guix manual

[Matt]

  On Sun, 18 Feb 2024 14:55:46 +0100  Josselin Poiret  wrote --- 

 > Matt m...@excalamus.com> writes:
 > 
 > > Specific mention of installing Guix's dependencies was removed.  Guix 
 > > being installed implies that its dependencies are also installed.
 > 
 > I don't agree here: it's often the case in Linux-land that binary
 > archives are provided without their dependencies included, assuming that
 > the user already has them, often by installing them via their own
 > package manager.  Keeping the mention that it is self-contained and that
 > the dependencies are also included might clarify the situation for some
 > users.

Thank you for the feedback.

I opted for only "self-contained" which seems to imply that dependencies are 
available, in addition to other things, perhaps like setting an environment or 
pathing.  If "self-contained" is distinct from "includes dependencies," we 
could append something like "...and includes all dependencies" to the last 
sentence.

I also tried to distinguish that it's the installation *process* which requires 
GNU-tar and Xz and not the final installation, since that's self-contained.

Otherwise, I tried to simplify the language:

- archived binaries -> a binary archive
- are often quicker -> often go faster
- which is described in the next sections -> described later

This version has fewer words and one more sentence.  However, each sentence has 
a single, hopefully clear, point:

1. What this section is about? Installing from a binary archive.
2. Why you might want this section? It's faster than building.
3. What's needed?  A Linux or Hurd-system with GNU-tar and Xz.
4. What do you get?  A self-contained Guix installation.

Original: Region has 5 lines, 3 sentences, 51 words, and 301 characters
v2:   Region has 5 lines, 4 sentences, 45 words, and 292 characters

If this is good, I can write up a commit message and format the change as a 
patch.

v2-0001-binary-installation.diff
Description: Binary data

Re: cannot boot after installation on VPS (via rescue system)

[jbranso]

February 21, 2024 at 4:54 AM, "Giovanni Biscuolo"  wrote:



> 
> Hello,
> 
> following the good guidelines from (info "(guix-cookbook) Running Guix
> on a Kimsufi Server") and (info "(guix-cookbook) Running Guix on a
> Linode Server") I'm developing a shell script to automate the "manual"
> installation of Guix on bare metal and VPS, you can find it attached to
> this email as bootstrap-guix.sh or at this git repo URL:
> https://gitlab.com/softwareworkers/swws/-/blob/master/infrastructure/hosts/cornouiller/bootstrap-guix.sh?ref_type=heads
> 
> The main purpose of the script is to allow me to install Guix on
> machines (bare metal or virtual) hosted by vendors who do not offer Guix
> in their OS installation options, since almost all vendors provides a
> rescue system that can be used to "manually" set up the environment,
> partition the target disk and lastly "guix system init..."
> 
> I've extensively tested the script locally (on bare metal and QEMU VMs),
> both booting the machines via grml [1] and Guix install image and it
> works as expected; I've also used it to install Guix on some bare metal.
> 
> Now I'm trying to use it on two VPS from two different vendors, booted
> in rescue mode, but after the installation (via bootstrap-guix.sh) when
> I reboot the VPS I get the usual grub menu but the boot process suddenly
> fails with this error (manually copied from web console, sorry for
> possible typos):
> 

I just logged into my linode server...your script defaults to a btrfs
filesystem right?  When I tried to add an additional disk in linode
just now, the only supported filesystem was ext4.  Does linode support
btrfs?

Joshua 

> --8<---cut here---start->8---
> 
> Scanning for Btrfs filesystems
> ice-9/boot9.scm:1685:16: In procedure raise-exception:
> In procedure mount: No such file or directory
> GRUB loading...
> Entering a new prompt. Type ',bt' for a backtrace or ',q' to continue.
> [...]
> scheme@(guile-user)> ,bt
> In gnu/build/linux-boot.scm:
>  637:8 3 (_)
>  435:8 2 (mount-root-filesystem "/dev/sda3" "btrfs" # _ #:flags ?)
> In unknown file:
>  1 (mount "/dev/sda3" "/root" "btrfs" 0 "compress=zstd")
> In ice-9/boot9.scm:
>  1685:16: 0 (raise-exception _ #:continuable? _)
> 
> --8<---cut here---end--->8---
> 
> In particular, I don't understand why the boot script is trying to mount
> the root filesystem at "/root" and not at "/" as it should: am I missing
> something?
> 
> I suspect that the issue depends on how the rescue system root is
> mounted (overlay filesystem) but I'm not sure; I cannot find a solution.
> 
> I'm also attaching:
> 
> - bootstrap-config.scm: automatically generated by the script and used
> by "guix system init..."
> 
> - bootstrap-mount-points.txt: automatically collected during installation
> 
> You can find all the files also here:
> https://gitlab.com/softwareworkers/swws/-/tree/master/infrastructure/hosts/cornouiller?ref_type=heads
> 
> Any idea please? :-O
> 
> Happy hacking! Gio'
> 
> [1] https://grml.org/, a rescue system based on Debian
> 
> -- 
> Giovanni Biscuolo
> 
> Xelera IT Infrastructures
>

Re: Feedback of the GNU Guix manual

[Maxim Cournoyer]

Hi Matt,

Thanks for the follow-up.

Matt  writes:

[...]

> #+begin_src diff
> diff --git a/doc/guix.texi b/doc/guix.texi
> index 4af830aed7..16349d4ec1 100644
> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -732,14 +732,16 @@ ready to use it.
>
>  @cindex installing Guix from binaries
>  @cindex installer script
> -This section describes how to install Guix on an arbitrary system from a
> -self-contained tarball providing binaries for Guix and for all its
> -dependencies.
>
>  This is often quicker than installing from source, which
> -is described in the next sections.  The only requirement is to have
> -GNU@tie{}tar and Xz.
> +This section describes how to install Guix from archived binaries.  Such
> +installations are often quicker than building from source, which is
> +described in the next sections.  Binary installations require a Linux or
> +Hurd-based system with GNU@tie{}tar and Xz.

Like Josselin, I prefer to keep the mention that the tarball archive
includes the transitive dependencies of Guix (it's explicit; "archived
binaries" is a bit vague to my taste).

As for the Linux or Hurd-based system, that seems like a good idea to
make things explicit.

I've pushed your adjusted suggestions with commit ec9c8b0c1a.

Thank you!

-- 
Maxim

cannot boot after installation on VPS (via rescue system)

[Giovanni Biscuolo]

Hello,

following the good guidelines from (info "(guix-cookbook) Running Guix
on a Kimsufi Server") and (info "(guix-cookbook) Running Guix on a
Linode Server") I'm developing a shell script to automate the "manual"
installation of Guix on bare metal and VPS, you can find it attached to
this email as bootstrap-guix.sh or at this git repo URL:
https://gitlab.com/softwareworkers/swws/-/blob/master/infrastructure/hosts/cornouiller/bootstrap-guix.sh?ref_type=heads

#!/bin/bash
# Copyright © 2023 Giovanni Biscuolo 
#
# bootstrap-guix.sh is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 3 of the
# License, or (at your option) any later version.
#
# bootstrap-guix.sh is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# A copy of the GNU General Public License is available at
# .

# bootstrap-guix.sh is a very opinionated script to install Guix
# System on a host booted in "rescue" mode
#
# The system is installed on a single disk BTRFS filesystem

# Used variables MUST be initialized.
set -o nounset

# -
# Variables

# Disks
# TODO: transform this in array TARGET_DISKS[TARGET_NUMDISKS], for multi disk setups
export TARGET_NUMDISKS=1
export TARGET_DISK_PART_SUFFIX=""
export TARGET_DISK1="/dev/sda"
export TARGET_SWAP_SIZE="6GB"

# Hostname
export TARGET_HOSTNAME="cornouiller"

# User and pub key (only one admin user for basic installation)
export TARGET_USERNAME="g"
export TARGET_USERGECOS="Giovanni Biscuolo"
TARGET_USERKEY="ssh-ed25519 C3NzaC1lZDI1NTE5ICqpr0unFxPo2PnQTmmO2dIUEECsCL3vVvjhk5Dx80Yb g...@xelera.eu"

# 
# Source os-release information
test -e /etc/os-release && os_release='/etc/os-release' || os_release='/usr/lib/os-release'
. "${os_release}"
echo "### INFO - Detected GNU/Linux distribution: ${PRETTY_NAME}."

# -
# Get package dependencies
export AUTO_INSTALLED=0

if [ $AUTO_INSTALLED -eq 0 ]; then
# Install dependencies with Guix, if available
if command -v guix &> /dev/null; then
	echo "### INFO - Installing dependencies via guix..."
	guix install util-linux parted dosfstools btrfs-progs gnupg
	export AUTO_INSTALLED=1
	echo "### END - Installing dependencies via guix."
fi
fi

if [ $AUTO_INSTALLED -eq 0 ]; then
# Install dependencies with apt, if available
if command -v apt &> /dev/null; then
	echo "### INFO - Installing dependencies via apt..."
	apt install util-linux parted dosfstools btrfs-progs gnupg
	export AUTO_INSTALLED=1
	echo "### END - Installing dependencies via apt."
fi
fi

# Give up installing and notify users
if [ $AUTO_INSTALLED -eq 0 ] ; then
echo "### INFO - I'm not able to automatically install dependencies on ${PRETTY_NAME}."
echo "Please check you have the following commands available: wipefs, parted, mkfs.fat, mkswap, mkfs.btrfs, btrfs, gpg."
echo "### END - Checking dependencies."
fi

# Abort on any error, from now
set -e 

# ###
# DO NOT EDIT this variables
# unless for debugging

# (minimal) OS configuration file name
export OS_CONFIG_FILE="bootstrap-config.scm"

# Target OS mount point
export TARGET_MOUNTPOINT="/mnt/guix"

# -
# Prepare the target system filesystem
echo "### START - Downloading guix install script."
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
chmod +x guix-install.sh
echo "### END - Downloading guix install script."  

# -
# Prepare the target system filesystem

# Wipe the disks
# TODO: use the array TARGET_DISKS[]
echo "### START - Wiping disks."
wipefs -af ${TARGET_DISK1}*
echo "### END - Wiping disks."

# Partition the disks
echo "### START - EFI system check."
if [ -e "/sys/firmware/efi/efivars" ]; then
IS_EFI=true
echo "System is EFI based. ($IS_EFI)"
else
IS_EFI=false
echo "System is BIOS grub based. ($IS_EFI)"
fi
echo "### END - EFI system check."

## Disk 1
echo "### START - partitioning ${TARGET_DISK1}."
parted ${TARGET_DISK1} --align=opt -s -m -- mklabel gpt

# partition p1 will be system boot
if $IS_EFI; then
# EFI system partition
BOOT_SIZE="501MiB"
parted ${TARGET_DISK1} --align=opt -s -m -- \
	   mkpart primary fat32 1MiB $BOOT_SIZE \
	   name 1 EFI-system \
	   set 1 esp on
else
# BIOS grub system partition
BOOT_SIZE="5MiB"
parted ${TARGET_DISK1} --align=opt -s -m -- \
	   mkpart grub 1MiB $BOOT_SIZE \
	   name 1 grub-1 \
	   set 1 bios_grub on
fi

Re: Proposal to turn off AOT in clojure-build-system

[Steve George]

Hi Maxime,

On 19 Feb, Maxime Devos wrote:
(...) 
> > Consequently, there is no specific statement saying 'Distributors should 
> > not AOT libraries' that I can point to.
> 
> In this bit about differences in perspective, I haven’t seen any mention of 
> AOT, hence the “Consequently” does not follow. The part that’s missing here 
> is that (IIUC) in Clojure, it is somewhat conventional to stuff the compiled 
> .class files in a superior Aryan JAR instead – the inferior UnderJARs you get 
> from the “guix install clj-whatever” equivalent would only contain 
> non-compiled .clj (and data files, whatever).
> 
> > But, I would like to draw attention to this thread on Clojureverse as the 
> > best source I could find:
> >Alex Miller is the main community manager for Clojure, and is a maintainer 
> >of the core libraries, so his perspective is key. He notes that, AOT code is 
> >tied to *specific versions of Clojure*:
> >
> >  "AOT'ed code is that it is inherently the product of a particular version 
> > of tthe Clojure compiler ... I would recommend NOT AOT compiling libraries" 
> > [4]
> 
> This reasoning does not follow – yes, it is tied to the Clojure version, so 
> what? Guix automatically rebuilds dependents when the dependency (in this 
> case, the Clojure compiler) changes.
(...)

I think this preceding sentence is the heart of different assumptions between 
us.

The Clojure packages we haave are for developers writing applications 
(libraries and tools). The ecosystem has very few end-user applications [0]. As 
a Clojure developer I can use the Clojure tools from Guix, and a few libraries. 
We (and all the other distributions) have a miniscule portion of the 
Clojure/Java library universe [1]. This leads to the following usage scenarios:

1. A developer installs Clojure from Guix, and uses libraries from outside Guix.
They can install the JVM/Clojure and some common tools (like clj-tools-cli). 
They will use libraries from elsewhere, including their own. AOT compilation is 
a problem because of the issue of mixed AOT and non-AOT.

2. A developer installs a Clojure from outside Guix, uses libraries from inside 
Guix
This will cause problems because the Guix Clojure libraries will have been 
AOT'd by a different version of the compiler. It's also fairly common to 
install/use parallel versions of Clojure/jvm due to different deployment needs, 
this is likely to cause difficult to find bugs.

I can see the sense of compiling to byte code if it's an end-user application. 
In that case we'd want to make the start-up as fast as possible. Your comments 
seem to have this use-case in mind.

But, today there aren't any such end-user Clojure applications in Guix.

> >I believe this means that with AOT code on, any user who installs a 
> >different version of Clojure from the one that we used to AOT the libraries 
> >*may* have problems.
> 
> Unlike, say, Maven, this situation simply does not happen in Guix, because we 
> don’t just download binaries and call it a day (except for some bootstrapping 
> stuff, but that’s not relevant for Clojure AOT), because we have functioning 
> recompilation of dependents, because of shebang patching, because binaries 
> that are to be invoked should not rely on the ambient CLASSPATH / 
> LD_LIBRARY_PATH / etc. and, if, the underlying binaries do rely on that, they 
> are wrapped (see wrap-program) to set them (or, at least, they should be, you 
> might find some bugs in this department if you go looking).
> 
> Even if they aren’t wrapped, then in that case the dependencies are 
> propagated-inputs, and you can only have a single version of a propagated 
> package in the same environment (barring stacking environment shenanigans, 
> but then you are looking for it and/or you can just report a bug about how 
> the binaries should be wrapped/classpath should be patched in/...).
> 

In this paragraph you're assumption is that a Guix user is only using libraries 
from within Guix. Hopefully, I've shown why this assumption is unlikely above.

You also mentioned Debian, and @e.hashiman [2] said that Clojure libraries are 
not AOT'd on Debian, while applications are. From what I can find there are 130 
packages in Debian with the word Clojure in them [3]. I looked at a selection 
and it seems true that Debian does not AOT libraries (and I can't find any 
Clojure 'apps'). For completeness I also checked what Clojars, the main 
distribution archive for Clojure developers, does:

- https://sources.debian.org/src/core-match-clojure/1.0.0-1/project.clj/
- Lein-based project - has to have :aot keyword - distributes as source 
files
- Clojure source files (.clj) in Debian
- Clojure source files in Clojars
- Byte compiled files in GUIX
- installed and inspected with jar -tvf

- https://sources.debian.org/src/data-csv-clojure/1.0.0-1/deps.edn/
- tools.deps project - has to have a specific aot alias - distributes as 
source files
- Clojure source files (.clj) in the