GNU bug report logs - #53700
Guix package is hardcoded in guix home

Previous Next

Package: guix;

Reported by: Gordon Quad <gordon <at> niflheim.info>

Date: Tue, 1 Feb 2022 16:05:02 UTC

Severity: normal

To reply to this bug, email your comments to 53700 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guix <at> gnu.org:
bug#53700; Package guix. (Tue, 01 Feb 2022 16:05:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gordon Quad <gordon <at> niflheim.info>:
New bug report received and forwarded. Copy sent to bug-guix <at> gnu.org. (Tue, 01 Feb 2022 16:05:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gordon Quad <gordon <at> niflheim.info>
To: bug-guix <at> gnu.org
Subject: Guix package is hardcoded in guix home
Date: Tue, 1 Feb 2022 14:19:57 +0000
guix home uses guix package directly imported from (gnu packages
package-management) gnu/home/services.scm:22

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n22

It looks like for now it is used only here gnu/home/services.scm:283

https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n284

It is quite unfortunte to see guix home to pull whole extra copy of guix
only to use few files to do gettext localization init.

If would be nice to be able to customize guix package used there so I
can make sure guix used by guix home is the same as in my guix daemon.




Information forwarded to bug-guix <at> gnu.org:
bug#53700; Package guix. (Wed, 02 Mar 2022 11:07:01 GMT) Full text and rfc822 format available.

Message #8 received at 53700 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Gordon Quad <gordon <at> niflheim.info>
Cc: 53700 <at> debbugs.gnu.org
Subject: Re: bug#53700: Guix package is hardcoded in guix home
Date: Wed, 02 Mar 2022 12:06:22 +0100
Hi,

Gordon Quad <gordon <at> niflheim.info> skribis:

> guix home uses guix package directly imported from (gnu packages
> package-management) gnu/home/services.scm:22
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n22
>
> It looks like for now it is used only here gnu/home/services.scm:283
>
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n284
>
> It is quite unfortunte to see guix home to pull whole extra copy of guix
> only to use few files to do gettext localization init.

Yes, it’s a bit heavy-handed.

> If would be nice to be able to customize guix package used there so I
> can make sure guix used by guix home is the same as in my guix daemon.

I’m not sure I understand.  As you write, the ‘guix’ package is used in
(gnu home services) only to get gettext catalogs; AFAICS it’s not used
for anything else.

Could you clarify what you had in mind?

Thanks,
Ludo’.




Information forwarded to bug-guix <at> gnu.org:
bug#53700; Package guix. (Fri, 31 Mar 2023 04:54:02 GMT) Full text and rfc822 format available.

Message #11 received at 53700 <at> debbugs.gnu.org (full text, mbox):

From: Andrew Tropin <andrew <at> trop.in>
To: Ludovic Courtès <ludo <at> gnu.org>, Gordon Quad
 <gordon <at> niflheim.info>
Cc: 53700 <at> debbugs.gnu.org
Subject: Re: bug#53700: Guix package is hardcoded in guix home
Date: Fri, 31 Mar 2023 08:52:51 +0400
[Message part 1 (text/plain, inline)]
On 2022-03-02 12:06, Ludovic Courtès wrote:

> Hi,
>
> Gordon Quad <gordon <at> niflheim.info> skribis:
>
>> guix home uses guix package directly imported from (gnu packages
>> package-management) gnu/home/services.scm:22
>>
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n22
>>
>> It looks like for now it is used only here gnu/home/services.scm:283
>>
>> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/home/services.scm#n284
>>
>> It is quite unfortunte to see guix home to pull whole extra copy of guix
>> only to use few files to do gettext localization init.
>
> Yes, it’s a bit heavy-handed.
>
>> If would be nice to be able to customize guix package used there so I
>> can make sure guix used by guix home is the same as in my guix daemon.
>
> I’m not sure I understand.  As you write, the ‘guix’ package is used in
> (gnu home services) only to get gettext catalogs; AFAICS it’s not used
> for anything else.
>
> Could you clarify what you had in mind?

I was hit by this one yesterday as well.  I tried to manage just a few
config files with Guix Home on foreign distro, but it started to
download 46 megabytes of guix package, while I expected it to work
completely offline.

-- 
Best regards,
Andrew Tropin
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guix <at> gnu.org:
bug#53700; Package guix. (Fri, 31 Mar 2023 12:13:02 GMT) Full text and rfc822 format available.

Message #14 received at 53700 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Andrew Tropin <andrew <at> trop.in>
Cc: 53700 <at> debbugs.gnu.org, Gordon Quad <gordon <at> niflheim.info>
Subject: Re: bug#53700: Guix package is hardcoded in guix home
Date: Fri, 31 Mar 2023 14:11:56 +0200
Hi,

Andrew Tropin <andrew <at> trop.in> skribis:

>> I’m not sure I understand.  As you write, the ‘guix’ package is used in
>> (gnu home services) only to get gettext catalogs; AFAICS it’s not used
>> for anything else.
>>
>> Could you clarify what you had in mind?
>
> I was hit by this one yesterday as well.  I tried to manage just a few
> config files with Guix Home on foreign distro, but it started to
> download 46 megabytes of guix package, while I expected it to work
> completely offline.

Ouch.  We should do better indeed, though I’m not sure how.

One solution would be to not need those catalogs on the build side in
the first place, which means making sure that error handling and logging
always happens on the “host side”, as is the case for pretty much
everything else.

Ludo’.




This bug report was last modified 363 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.