From: "Ludovic Courtès" <ludo@gnu.org>
To: Andrew Tropin <andrew@trop.in>
Cc: guix-devel@gnu.org, Xinglu Chen <public@yoctocell.xyz>
Subject: Re: On the naming of System and Home services modules.
Date: Tue, 28 Sep 2021 14:17:03 +0200 [thread overview]
Message-ID: <87ee98dhds.fsf@gnu.org> (raw)
In-Reply-To: <871r5eqtu2.fsf@trop.in> (Andrew Tropin's message of "Fri, 24 Sep 2021 11:08:21 +0300")
Hi Andrew,
Andrew Tropin <andrew@trop.in> skribis:
> On 2021-09-23 22:08, Ludovic Courtès wrote:
[...]
>> Silly question, but why do we need to have two different configuration
>> record types in the first place?
To be clear: you’ll have to be very convincing as I know all too well
the cost of maintaining such a thing :-) and can already foresee that
this would also be annoying to users.
> 1. Different fields (for example system services in many cases wants to
> know the username, which will be used to run process from, home services
> will probably use the user's username and won't rely on this field, home
> services on the other hand can have something like xdg-flavor? or
> anything else unrelated to system services).
>
> Even if fields are not conflicting with each other, it's very likely
> that it will introduce a confusion: user of Guix Home on foreign distro
> will be guessing why there is a field in configuration record, which
> doesn't make sense for a home service.
Do you have specific examples? The user name example isn’t a convincing
one for me, at least not in the abstract.
> 2. Different default values. $HOME/mail or /var/spool/mail? Even if we
> can technically bypass those problems, semantically the values will be
> incorrect.
Again, any specific example? How frequently does this problem occur?
It could be solved, say, by having a ‘home-service?’ Boolean in the
config, which default values would take into account.
>> Sharing configuration between Home and System sounds important to me: it
>> means users can easily move services from one to the other, which is
>> pretty big deal. It also means we’d have much less code to maintain.
>>
>> Would that be feasible? (Apologies if this has already been discussed!)
>
> I find records to be a very rigid and hard to reuse
We can discuss the suitability of records, but we need an immediate
solution to the problem, especially now that it’s in ‘master’.
Duplicating configuration records for each and every service could have
a huge maintenance cost that we’re probably not willing to pay.
>> Also, I proposed earlier a possible way to generate a Home service type
>> from the corresponding System service type—or, IOW, to generate a Home
>> service type graph from the System graph. Does that sound feasible?
>
> Not sure what you mean here, can you share a link to the proposal or
> elaborate one more time, please.
I can’t find the message anymore. The suggestion is to have helpers to
“rewrite” the System service type graph for Home, so you could do things
like:
(define home-profile-service-type
(system->home-service-type profile-service-type))
(define home-mcron-service-type
(system->home-service-type mcron-service-type))
because fundamentally, these two things are the same as their System
counterpart, except that they graph is rooted in ‘home-service-type’ (or
whatever it’s called) instead of ‘system-service-type’.
Of course there are exceptions, but it may be possible to do that for
quite a few services.
Thoughts?
Ludo’.
next prev parent reply other threads:[~2021-09-28 12:17 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-15 8:47 On the naming of System and Home services modules Andrew Tropin
2021-09-15 10:09 ` Maxime Devos
2021-09-15 13:15 ` Andrew Tropin
2021-09-15 13:06 ` Xinglu Chen
2021-09-15 14:50 ` Katherine Cox-Buday
2021-09-16 10:01 ` Andrew Tropin
2021-09-16 9:57 ` Andrew Tropin
2021-09-17 9:28 ` Xinglu Chen
2021-09-17 11:35 ` Andrew Tropin
2021-09-19 14:54 ` Xinglu Chen
2021-09-23 20:08 ` Ludovic Courtès
2021-09-24 8:08 ` Andrew Tropin
2021-09-28 12:17 ` Ludovic Courtès [this message]
2021-09-24 13:35 ` Code sharing between system and home services (was Re: On the naming of System and Home services modules.) Xinglu Chen
2021-09-24 14:03 ` Maxime Devos
2021-09-24 15:39 ` Xinglu Chen
2021-09-24 17:02 ` Maxime Devos
2021-09-28 12:19 ` Ludovic Courtès
2021-09-28 6:03 ` Andrew Tropin
2021-09-24 15:32 ` Joshua Branson
2021-09-28 12:21 ` Ludovic Courtès
2021-09-29 13:52 ` Maxime Devos
2021-10-02 14:27 ` Ludovic Courtès
2021-10-02 22:13 ` Code sharing between system and home services Vagrant Cascadian
2021-10-04 14:34 ` Ludovic Courtès
2021-10-03 8:45 ` Code sharing between system and home services (was Re: On the naming of System and Home services modules.) Maxime Devos
2021-10-04 14:32 ` Ludovic Courtès
2021-10-04 16:14 ` Maxime Devos
2021-10-06 13:12 ` Ludovic Courtès
2021-09-28 2:32 ` Maxim Cournoyer
2021-09-16 3:05 ` On the naming of System and Home services modules Ryan Prior
2021-09-16 8:50 ` Andrew Tropin
2021-09-17 13:43 ` pinoaffe
2021-09-23 20:10 ` Ludovic Courtès
2021-09-28 6:32 ` Andrew Tropin
2021-09-28 12:26 ` Ludovic Courtès
2021-09-28 13:48 ` Andrew Tropin
2021-09-28 19:36 ` Oleg Pykhalov
2021-10-02 14:22 ` Ludovic Courtès
2021-10-02 17:23 ` Oleg Pykhalov
2021-09-28 15:25 ` Xinglu Chen
2021-10-02 14:25 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ee98dhds.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=andrew@trop.in \
--cc=guix-devel@gnu.org \
--cc=public@yoctocell.xyz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).