Visiting a future of GNU? (was Re: Please don't leave GNU)

[Simon Tournier]

Hi Caleb,

On Fri, 28 Mar 2025 at 18:26, Caleb Herbert  wrote:

> I use Guix primarily because of its commitment to user freedom and its 
> united front with the GNU Project.

Cool!  As many of us. :-)

If I might, I think your message and replies in the thread lock the
conversion in some undecidable debate.  Why?  Because your wording leads
to oppose subjective interpretations, especially of the past.  Do not
take me wrong, I mean, for the same event, one might see some good when
other might see some bad.  Or one event (good or bad) is opposed to
another event (bad or good).  Do we need to discuss personal opinions
again?  And again.  Somehow, talk does not cook the rice. :-)

About RMS, the History – with a big H – will judge and it appears to me
pointless to force today one view or the other based on this very
subjective interpretation.  Well, my yet another personal opinion. :-)

Today, Richard is 71 years old.  The question isn’t the past but the
future: What will be GNU in 5 years?  10 years? 20 years?  40 years?
What does it mean being part of GNU once Richard will be “retired”?
Please do not take me wrong, I wish all the best to Richard and a very
long life!  Being just a human implies becoming older and older and
passing away.  For one, not a personal opinion. ;-)

I think the question “leave GNU or not?” is empty.  Because it asks to
look back when we must focus on look next.

To be frank: I asked to Richard his thoughts about the future of GNU.
Based on his answer, I’m not sure Richard is deeply preparing the future
of GNU once Richard will “retire”.  And I totally miss why people focus
again and again on Richard when it comes to speak about GNU.

After 40 years, when people are still putting the founder in the middle
of the project, it means either the project failed, either the project
is going to fail once the very founder stops their activities.  Or,
slippery slope – without any willing to be harsh –, either people devote
a cult of personality to the founder.  No?  After 40 years…

To be honest, I do not mind about Richard.  I mean, I am very grateful
to all Richard’s contributions – and _grateful_ is probably too weak
here – I’m very grateful to all the heritage, and for sure, I don’t want
to throw away anything.  We have received all this heritage as a gift,
the question is what do we do with the heritage?  The answer is fully
independent on who did the gift, no?

All that to say, the question isn’t “leave GNU or not?”, the question is
“what GNU means to us?“ or what do we do to build the world we want.
Today, what’s GNU?  Tomorrow, how will GNU’s ideas survive?

Long enough. :-)  I shared more thoughts here:

https://simon.tournier.info/posts/2024-11-01-visiting-future-gnu.html

It appears to me much more fruitful to discuss what’s the next 40 years
of the humanist project dreamed by GNU 40 years ago rather than nitpick
about belonging to some GNU trademark, IMHO.

Cheers,
simon

Alist and serializer backed service configuration?

[Hilton Chain]

Hi Guix,

(Cc'd the Home Team)

Lately, Andrew's proposal[1] on using free-style configurations for services
came to my mind again.  Ludovic was againt it for potential generation of
invalid config files and obscure error messages.  But how about treating it as
an escape hatch like ‘extra-config’?

I'm aware of two inflexiblities in our service configurations:

1. Too many configuration fields.  e.g. bluetooth-configuration
  I don't think all the fields have at least one user. :) I remember the
  experience of trying to find ‘auto-enable?’ from the documentation.  Keeping
  track of upstream updates would be a pain, and it requires knowledge to write
  readable documentation for some fields.

  If it's a port of the original configuration, why not supply an INI file
  directly?  (extra-config)

  If the point is to use Scheme, why not use an alist and serialize it to INI?
  (RDE, free-style configurations)

2. Need of manually exposing interfaces.  e.g. those from shepherd-service.


I have the following approach in mind that may solve these inflexiblities:

1. Configuration interface consists of regular fields + free-style config + 
extra-config.
  This helps reduce configuration fields to those we know and use.  We can also
  maintain a better documentation.

2. Merge regular fields and free-style config into an alist, service extensions
  will make use of this alist and extra-config.  With this we can utilize
  existing serializers from Guile packages directly.

--8<---cut here---start->8---
'((shepherd . ((requirement . <...>)))
  (config . <...>))
--8<---cut here---end--->8---

  free-style config uses the same format as this alist.

  It would be better if we can deserialize extra-config and merge it into the
  alist as well.

This is an initial thought and I don't have an implementation at the moment,
I'll try to make some example services and see how it goes.

Thanks
---
1: [bug#65119] [PATCH 0/8] Sharing service code between Home and System
https://yhetil.org/guix-patches/874jk3sk57@trop.in/

Re: Visiting a future of GNU? (was Re: Please don't leave GNU)

[Caleb Herbert]

Hi Simon,

On 4/2/25 03:03, Simon Tournier wrote:

It appears to me much more fruitful to discuss what’s the next 40 years
of the humanist project dreamed by GNU 40 years ago rather than nitpick
about belonging to some GNU trademark, IMHO.


I agree that we must move beyond Richard and take the reigns. This is 
already happening in GNU proper.  I disagree that we should take away 
the old man's honor over nit-picking the things he says.  I don't think 
we should blot out his name or disparage him.


--
Caleb Herbert
https://calebh.top/
BEGIN:VCARD
VERSION:4.0
N:Herbert;Caleb;;;
EMAIL;PREF=1;TYPE=home:c...@bluehome.net
TEL;TYPE=cell;VALUE=TEXT:+1 816 892 9669
IMPP:xmpp:ca...@csh.snikket.chat
URL;TYPE=home:https://calebh.top/
ADR:;;PO box 234;East Lynne;Missouri;64743;USA
BDAY;VALUE=DATE:19960211
END:VCARD

Re: GNU & Guix

[Caleb Herbert]

Hi, signer of Document!

Pardon my inflammatory remarks.

On 4/2/25 01:21, Tobias Geerinckx-Rice wrote:

What do you expect this kind of disruptive behaviour to achieve?  It is 
comically unclear.


For a long time, I and many others have felt unheard.  I'm sorry I 
blindly aired my frustration here, but I'm glad I've been heard now.


--
Caleb Herbert
https://calebh.top/
BEGIN:VCARD
VERSION:4.0
N:Herbert;Caleb;;;
EMAIL;PREF=1;TYPE=home:c...@bluehome.net
TEL;TYPE=cell;VALUE=TEXT:+1 816 892 9669
IMPP:xmpp:ca...@csh.snikket.chat
URL;TYPE=home:https://calebh.top/
ADR:;;PO box 234;East Lynne;Missouri;64743;USA
BDAY;VALUE=DATE:19960211
END:VCARD

Re: Slow guix pull? (was Re: Please don't leave GNU)

[45mg]

Simon Tournier  writes:

> Hi,
>
> On Wed, 02 Apr 2025 at 09:01, 45mg <45mg.wri...@gmail.com> wrote:
>
>>> 1) Actual 'git pull' equivalent.
>>>
>>> 2) The 'guix authenticate' dance on the commits.
>>>
>>> 3) The Guix derivation part.
>>>
>>> In some settings, I fear step 1 and 2 takes comparable time as 3.
>>
>> In my experience, authentication is pretty fast. `guix git authenticate`
>> processes hundreds of commits in under a second.
>
> Yes.  Although it could be a bit improved – see [1] – that’s not the
> main bottleneck, from my experience too.

Agreed. Back when I was messing with the authentication code to figure
out how to do authenticated forks, it quickly became clear that the
rate-limiting step within authentication is the verification of
individual commits. I didn't see any way to optimize that. The bit
before that - calling `commit-difference` to get the set of commits to
authenticate - rarely takes more than a second or two, even when
authenticating from scratch.

[...]
> Could you share the output of
>
> --8<---cut here---start->8---
> scheme@(guix-user)> ,use(git)
> scheme@(guix-user)> ,use(guix git)
> scheme@(guix-user)> (define url "https://git.savannah.gnu.org/git/guix.git";)
> scheme@(guix-user)> (define cache-directory (url-cache-directory url 
> (%repository-cache-directory)))
> scheme@(guix-user)> (openable-repository? cache-directory)
> $1 = #t
> scheme@(guix-user)> cache-directory
> $2 = 
> "/home/simon/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq"
> --8<---cut here---end--->8---
>
> ?  I guess, openable-repository? returns #f instead of #t, right?

No, it returns #t; contrary to what I suspected, the caching is actually
done correctly. See my previous message.

> Well, I think the issue is from update-cached-checkout in (guix git)…
> #
>> It's probably a bug with the caching; I pull from a local authenticated
>> fork, which can't be too common, so it makes sense that this hasn't been
>> caught before. I haven't had time to properly debug it yet (deleting the
>> cache does not help).
>
> …and something along:
>
>(let* ((cache-exists? (openable-repository? cache-directory))
>   (repository(if cache-exists?
>  (repository-open cache-directory)
>  (clone/swh-fallback url ref cache-directory
>  #:verify-certificate?
>  verify-certificate?
>  ;; Only fetch remote if it has not been cloned just before.
>  (when (and cache-exists?
> (not (reference-available? repository ref)))
>(remote-fetch (remote-lookup repository "origin")
>  #:fetch-options (make-default-fetch-options
>   #:verify-certificate?
>   verify-certificate?)))
>
> Therefore, that’s why my guess is about openable-repository?

Yup, it's the `remote-fetch` part. Again, see my previous message.

> Cheers,
> simon
>
>
> 1: comparing commit-relation using Scheme+libgit2 vs shellout plumbing Git
> Simon Tournier 
> Tue, 12 Sep 2023 00:48:30 +0200
> id:865y4gz5q9@gmail.com
> https://lists.gnu.org/archive/html/guix-devel/2023-09
> https://yhetil.org/guix/865y4gz5q9@gmail.com
>
> 2: bug#65787: time-machine is doing too much network requests
> Simon Tournier 
> Wed, 06 Sep 2023 18:26:18 +0200
> id:87wmx3mfo5@gmail.com
> https://issues.guix.gnu.org/65787
> https://issues.guix.gnu.org/msgid/87wmx3mfo5@gmail.com
> https://yhetil.org/guix/87wmx3mfo5@gmail.com

Re: Per-user Guix installations

[Konrad Hinsen]

Hi Ludo,

> But then, the problem is that ‘guix pull’ or in fact any ‘guix’ command
> will give you non-relocatable binaries.  So you need to somehow map,
> say, ~/.local/state/guix/store to /gnu/store for all the user sessions,
> as seamlessly as possible.

Or change the location of the store and give up on substitutes. Not
good, I know.

> If a systemd user mount is not an option, then we could provide a
> ‘guixify’ statically-linked binary that would spawn $SHELL in a mount
> namespace where /gnu/store is available.  But needless to say, that’d be
> much less convenient.

It might be OK for a purely pedagogical installation, but really
inconvenient for daily use.

Cheers,
  Konrad.
-- 
-
Konrad Hinsen
Centre de Biophysique Moléculaire, CNRS Orléans
Synchrotron Soleil - Division Expériences
Saint Aubin - BP 48
91192 Gif sur Yvette Cedex, France
Tel. +33-1 69 35 97 15
E-Mail: konrad DOT hinsen AT cnrs DOT fr
http://dirac.cnrs-orleans.fr/~hinsen/
ORCID: https://orcid.org/-0003-0330-9428
Mastodon: @khinsen@scholar.social
-

Re: Slow guix pull? (was Re: Please don't leave GNU)

[45mg]

Simon Tournier  writes:

> Re,
>
> On Wed, 02 Apr 2025 at 09:41, 45mg <45mg.wri...@gmail.com> wrote:
>
>>>  every single time I run `guix
>>> pull` it appears to do nothing for like 2 minutes, and then the progress
>>> bars display as it pulls the entire repo instead of using a cached
>>> checkout, which takes forever.
>
> [...]
>
>
>> `git_remote_fetch` (via the guile-git `remote-fetch` binding). I tested
>> this function on the cached clone [1] and it's /extremely/ slow.
>
> This does not explain what you report above.  Being slow once the cached
> had been created is somehow “known” – libgit2 corner-cases – but fully
> cloning at each “guix pull” is a bug because it should not if
> openable-repository? does what it’s expected. :-)

I had /assumed/ it was fully cloning (because of how long it takes), but
actually it looks like I was wrong.

When "the progress bars display" as I wrote above, the messages
associated with them correspond to the `show-progress` function in (guix
git), which is passed to `remote-fetch` via
`make-default-fetch-options`; this is the only place where it's used.
And `remote-fetch` is only called if `guix pull` didn't just do a fresh
clone. So it isn't doing a fresh clone after all.

As a side note - if I delete ~/.cache/guix/checkouts/, the resulting
fresh clone is actually /faster/ than the fetching that happens when the
cache exists. If only there was a CLI option to inhibit the caching...

> Cheers,
> simon

A silly concern about substitute servers

[Pan Xie]

Hi there


While reading the Guix reference manual, I get a silly concern. I 
believe it is silly because this concern must have been addressed, but I 
am still interested in details.



My concern is about the storage resources of the substitute servers. 
Since guix is a functional package manager, each package (e.g. emacs) 
must have lots of builds, with (sometimes, even slightly)


differences of inputs.  The value of a substitute server is to pre-build 
these packages, and provide them on demand. I can't figure out how many 
different emacs builds exist at a time on


a substitute server, but I guess there are many. On the other hand, guix 
also provides time-machine functionality, which allow users use versions 
of packages years ago. So my concern and questions:



1. Does a substitute server keeps all the packages it build? If the 
answer is yes, won't it consume huge storage resources? If the answer is 
no, then the user who use time-machine travel back to


    years before have to build all the packages from scratch?


2. If I am going to create a mirror of guix's official substitute 
server, what is the requirement of the storage?



3. Does a package really has lots of build on a substitute server? For 
example, emacs-29.1 has lots of inputs. I guess each time there is a 
commit to guix repository which change the inputs, there will be a build


    of it, so there must be lots of emacs-29.1 builds, with different 
hash numbers. Or am I wrong?



Regards

Pan

Re: A silly concern about substitute servers

[Ricardo Wurmus]

Pan Xie  writes:

1. Does a substitute server keeps all the packages it build? If 
the
answer is yes, won't it consume huge storage resources? If the 
answer

is no, then the user who use time-machine travel back to

    years before have to build all the packages from scratch?


You are correct on all points.  In practice some substitute 
servers will drop some substitutes that haven't been accessed in a 
while.


On ci.guix.gnu.org we have attached 100TB storage of which 37TB 
are in use (for the cache of substitutes, the active store, and 
the system).


2. If I am going to create a mirror of guix's official 
substitute

server, what is the requirement of the storage?


This depends on whether you intend to keep everything or only 
store a recent subset.


3. Does a package really has lots of build on a substitute 
server? For
example, emacs-29.1 has lots of inputs. I guess each time there 
is a
commit to guix repository which change the inputs, there will be 
a

build

    of it, so there must be lots of emacs-29.1 builds, with 
different

hash numbers. Or am I wrong?


You are not wrong.  In this case many files will be shared among 
these different builds, though, so on a deduplicating file system 
this is not much of a problem.  Storage requirements can go up 
when the similarities between builds are hidden from the 
deduplicating storage, e.g. when the substitutes are stored as 
compressed archives.


--
Ricardo

[fr] Moment de convivialité Guix@Paris en avril

[Tanguy Le Carrour]

(Warning: this email is in french because the meeting is supposed
to be held in French… and in person.)

Bonjour Guix,

Jeudi 17 avril à 19h se tiendra la septième soirée de la 3ème saison
des rencontres Guix à Paris.

Retrouvez tous les détails sur l’Agenda du Libre :


En espérant vous y retrouver nombreu·ses.

-- 
Tanguy

Re: Slow guix pull? (was Re: Please don't leave GNU)

[Simon Tournier]

Re,

On Wed, 02 Apr 2025 at 09:41, 45mg <45mg.wri...@gmail.com> wrote:

>>  every single time I run `guix
>> pull` it appears to do nothing for like 2 minutes, and then the progress
>> bars display as it pulls the entire repo instead of using a cached
>> checkout, which takes forever.

[...]


> `git_remote_fetch` (via the guile-git `remote-fetch` binding). I tested
> this function on the cached clone [1] and it's /extremely/ slow.

This does not explain what you report above.  Being slow once the cached
had been created is somehow “known” – libgit2 corner-cases – but fully
cloning at each “guix pull” is a bug because it should not if
openable-repository? does what it’s expected. :-)

Cheers,
simon

Re: Slow guix pull? (was Re: Please don't leave GNU)

[Simon Tournier]

Hi,

On Wed, 02 Apr 2025 at 09:01, 45mg <45mg.wri...@gmail.com> wrote:

>> 1) Actual 'git pull' equivalent.
>>
>> 2) The 'guix authenticate' dance on the commits.
>>
>> 3) The Guix derivation part.
>>
>> In some settings, I fear step 1 and 2 takes comparable time as 3.
>
> In my experience, authentication is pretty fast. `guix git authenticate`
> processes hundreds of commits in under a second.

Yes.  Although it could be a bit improved – see [1] – that’s not the
main bottleneck, from my experience too.

Somehow, #2 is far to be comparable from #1 and #3.  Again, from my
experience.


> The initial `git pull` part can be surprisingly slow, though. And it's
> not always a network thing. For example, every single time I run `guix
> pull` it appears to do nothing for like 2 minutes, and then the progress
> bars display as it pulls the entire repo instead of using a cached
> checkout, which takes forever.

Yes, that’s what I was meaning when mentioning bug#65787 [2].  Somehow,
it’s kind of “network inefficiencies”.  It does not necessarily come
from the performance of the network link itself but it comes from poor
management of the network, IMHO.

However, what you describe seems more a bug.  If you run once “guix
pull”, then it will take forever to “git clone”.  The next “guix pull”
should be fast since it only does either “git pull” (or “git checkout”
when you run “guix pull --commit=123abc” and 123abc is already part of
the cache repository).

Could you share the output of

--8<---cut here---start->8---
scheme@(guix-user)> ,use(git)
scheme@(guix-user)> ,use(guix git)
scheme@(guix-user)> (define url "https://git.savannah.gnu.org/git/guix.git";)
scheme@(guix-user)> (define cache-directory (url-cache-directory url 
(%repository-cache-directory)))
scheme@(guix-user)> (openable-repository? cache-directory)
$1 = #t
scheme@(guix-user)> cache-directory
$2 = 
"/home/simon/.cache/guix/checkouts/pjmkglp4t7znuugeurpurzikxq3tnlaywmisyr27shj7apsnalwq"
--8<---cut here---end--->8---

?  I guess, openable-repository? returns #f instead of #t, right?

Well, I think the issue is from update-cached-checkout in (guix git)…
#
> It's probably a bug with the caching; I pull from a local authenticated
> fork, which can't be too common, so it makes sense that this hasn't been
> caught before. I haven't had time to properly debug it yet (deleting the
> cache does not help).

…and something along:

   (let* ((cache-exists? (openable-repository? cache-directory))
  (repository(if cache-exists?
 (repository-open cache-directory)
 (clone/swh-fallback url ref cache-directory
 #:verify-certificate?
 verify-certificate?
 ;; Only fetch remote if it has not been cloned just before.
 (when (and cache-exists?
(not (reference-available? repository ref)))
   (remote-fetch (remote-lookup repository "origin")
 #:fetch-options (make-default-fetch-options
  #:verify-certificate?
  verify-certificate?)))

Therefore, that’s why my guess is about openable-repository?

Cheers,
simon


1: comparing commit-relation using Scheme+libgit2 vs shellout plumbing Git
Simon Tournier 
Tue, 12 Sep 2023 00:48:30 +0200
id:865y4gz5q9@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-09
https://yhetil.org/guix/865y4gz5q9@gmail.com

2: bug#65787: time-machine is doing too much network requests
Simon Tournier 
Wed, 06 Sep 2023 18:26:18 +0200
id:87wmx3mfo5@gmail.com
https://issues.guix.gnu.org/65787
https://issues.guix.gnu.org/msgid/87wmx3mfo5@gmail.com
https://yhetil.org/guix/87wmx3mfo5@gmail.com

Per-user Guix installations

[Ludovic Courtès]

Hi Konrad,

Konrad Hinsen  skribis:

> In the long run, I'd rather have "personal Guix". Or maybe call it
> "guik", the little-used singular of "guix" ;-) Meaning Guix running
> entirely in a user's home directory. If you want a sandbox, just create
> a new user account for it. Unlike the Docker workaround, it would be
> efficient enough for real work. And it would make Guix a realistic
> alternative to Conda for many people.

I’m interested in this use case, but there’s still a couple of open
issues.

Right now, running:

  guix pack -R guix --localstatedir --profile-name=current-guix

gives you a relocatable Guix tarball that you can extract in $HOME and
then run, say:

  GUIX_STATE_DIRECTORY=$HOME/var GUIX_LOG_DIRECTORY=$HOME/var/log \
./bin/guix-daemon &
  GUIX_DAEMON_SOCKET=$HOME/var/daemon-socket/socket \
./bin/guix build hello

This needs more testing and streamlining, so you don’t have to set three
environment variables and to manually start the daemon.

But then, the problem is that ‘guix pull’ or in fact any ‘guix’ command
will give you non-relocatable binaries.  So you need to somehow map,
say, ~/.local/state/guix/store to /gnu/store for all the user sessions,
as seamlessly as possible.

I think user systemd instances could save us: it might be that we can
provide a per-user .mount file that would bind-mount the store.  But
again, this needs to be tested to see if it can actually work.

If a systemd user mount is not an option, then we could provide a
‘guixify’ statically-linked binary that would spawn $SHELL in a mount
namespace where /gnu/store is available.  But needless to say, that’d be
much less convenient.

Thoughts?

Ludo’.

Re: Slow guix pull? (was Re: Please don't leave GNU)

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

Simon Tournier  writes:

> To my knowledge, the main bottleneck on most machines is the part
> “Computing Guix derivation...“ and sadly it’s not substitutable.

I'm not sure that is the full story.  Is there some way to instrument
'guix pull' to report what it is spending time on?  I think there are at
least three different steps involved:

1) Actual 'git pull' equivalent.

2) The 'guix authenticate' dance on the commits.

3) The Guix derivation part.

In some settings, I fear step 1 and 2 takes comparable time as 3.

I think understanding what is taking a long time is the first towards
improving things.  If we can shave off 10 minutes of an initial 80k+
commit 'guix pull' by optimizing 'guix authenticate', that would help.
But if that step takes 5 seconds, there is no need to optimize it.

I've personally optimized step 1 by using a Git mirror [1] instead of
using Savannah.  It seems to speed up things a bit, but primary
availability is better because of the recent outages.

/Simon

[1] https://gitlab.com/debdistutils/guix/mirror


signature.asc
Description: PGP signature

Re: Visiting a future of GNU? (was Re: Please don't leave GNU)

[Cayetano Santos]

>Wed 02 Apr 2025 at 10:03, Simon Tournier  wrote:

> Hi Caleb,
>
> On Fri, 28 Mar 2025 at 18:26, Caleb Herbert  wrote:
>
>> I use Guix primarily because of its commitment to user freedom and its
>> united front with the GNU Project.
>
> Cool!  As many of us. :-)

At this point, I cannot avoid pointing out to one of the main reasons of
using GNU related software: its openness, its high quality standards,
its real life utility and the fact that they solve in a very convenient
way everyday’s problems.

Many people use Guix just because it is a wonderful piece of code,
thanks to the contribution of people in this community, as such is the
case of many other projects.


signature.asc
Description: PGP signature

Re: Slow guix pull? (was Re: Please don't leave GNU)

[45mg]

Simon Josefsson via "Development of GNU Guix and the GNU System
distribution."  writes:

> Simon Tournier  writes:
>
>> To my knowledge, the main bottleneck on most machines is the part
>> “Computing Guix derivation...“ and sadly it’s not substitutable.
>
> I'm not sure that is the full story.  Is there some way to instrument
> 'guix pull' to report what it is spending time on?  I think there are at
> least three different steps involved:
>
> 1) Actual 'git pull' equivalent.
>
> 2) The 'guix authenticate' dance on the commits.
>
> 3) The Guix derivation part.
>
> In some settings, I fear step 1 and 2 takes comparable time as 3.

In my experience, authentication is pretty fast. `guix git authenticate`
processes hundreds of commits in under a second.

The initial `git pull` part can be surprisingly slow, though. And it's
not always a network thing. For example, every single time I run `guix
pull` it appears to do nothing for like 2 minutes, and then the progress
bars display as it pulls the entire repo instead of using a cached
checkout, which takes forever.

It's probably a bug with the caching; I pull from a local authenticated
fork, which can't be too common, so it makes sense that this hasn't been
caught before. I haven't had time to properly debug it yet (deleting the
cache does not help).

Re: Alist and serializer backed service configuration?

[Rutherther]

Hello Hilton,

Hilton Chain  writes:

>
> 2. Need of manually exposing interfaces.  e.g. those from shepherd-service.
>

I feel like this has been a topic mentioned multiple times in the last
few weeks on this mailing list. Here I have e-mail from Carlo Zancanaro
in mind, "Configuring shepherd services belonging to system services" (I
don't know how to 'mention' e-mails in a good way, if you have tips,
please do share them),
where also this patch https://issues.guix.gnu.org/27155 has been
mentioned.

I think it's a pity we don't have a generic solution merged yet,
especially given the patch that is 8 years old and Ludo mentions in it
"It was long overdue.", I agree.
The general finalizer approach would allow for exposing further
procedures that would alter the services after they are made, things
like this would become possible to do easily and we could build on it
further, functions like '(finalize-shepherd-service "service" (lambda
(config) (.. (inherit (config)' and more specific ones like
(shepherd-override-auto-start? #f)'.

Regards,
Rutherther