GNU bug report logs - #65119
[PATCH 0/8] Sharing service code between Home and System

Previous Next

Full log

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Andrew Tropin <andrew <at> trop.in>
Cc: 65119 <at> debbugs.gnu.org, 宋文武 <iyzsong <at> envs.net>,
 paren <at> disroot.org
Subject: Re: [bug#65119] [PATCH 0/8] Sharing service code between Home and
 System
Date: Fri, 13 Oct 2023 18:05:14 +0200

Hi Andrew,

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

> We have
>
> (extensions
>  (list (service-extension account-service-type
>                           (const %dicod-accounts))
>        (service-extension shepherd-root-service-type
>                           dicod-shepherd-service)))
>
>
> We can do
>
> (home-environment
>  (services
>   (list (service dicod-service-type)))
>  (service-mapping
>   `((,shepherd-root-service-type . ,home-shepherd-service-type)
>     (,account-service-type . ,ignore-service-type))))

As a user writing the ‘home-environment’ declaration, I don’t want to
know whether a Home service is implemented by mapping a System service
to Home, or whether it’s a fully separate implementation.

To me, users shouldn’t have to specify service mappings at all; service
mapping is a tool at the disposal of service writers.

> Now you can use the same service type and configuration record in
> both operating-system and home-environment and use/ignore/interpret the
> configuration fields values based on the environment we are building
> this thing for.
>
> Of course service-mapping default value can be generated upfront and
> stored in %guix-home-service-mapping or something like that.
>
> This way we will get rid of almost all home- services and related
> configurations.
>
> Keep in mind that it's a raw idea, not a well-designed solution yet.

The good thing is that we seem to agree on the general idea of having a
way to map System services to Home.

My take is that the mapping is an implementation detail that users do
not need to be aware of.

> The reason I'm suggesting to revert this patch series is because it
> feels to me as a partial solution on the wrong level of abstraction,
> which cures the symptoms and also introduces shortcomings and
> potentially makes it harder to introduce a proper solution in the
> future.

I disagree with this assessment.

> If this problem is urgent/demanding for you, please invite me for
> working or collaborating on the solution explicitly, I plan work on it
> anyway, but probably not earlier than the next year.  I catched this
> thread accidentially BTW, thanks to 宋文武 for CCing me.

This problem has been discussed pretty much since Home was merged in
Guix¹; we’ve all had ample time to think about it and to my knowledge
this patch series is the only proposal that was ever brought.

I’ll close this bug for clarity.  I remain open to discussion on the
implementation of System -> Home service mapping.  I think further
discussion should happen in the context of incremental changes to the
implementation of that mapping mechanism, in a dedicated issue.

Thank you,
Ludo’.

¹ The cover letter at <https://issues.guix.gnu.org/65119> mentions two
  services that would have been duplicated if we didn’t have this
  mechanism.

Previous Next

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