guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#63985] [PATCH v3 00/11] Service subsystem improvements


From: Liliana Marie Prikler
Subject: [bug#63985] [PATCH v3 00/11] Service subsystem improvements
Date: Sat, 16 Sep 2023 23:55:59 +0200
User-agent: Evolution 3.46.4

Am Samstag, dem 16.09.2023 um 22:22 +0100 schrieb Bruno Victal:
> Hi all,
> 
> I've been pondering about the changes here and would like to comment
> on them:
> 
> On 2023-06-26 22:57, Bruno Victal wrote:
> > Bruno Victal (11):
> >   services: configuration: Simplify normalize-extra-args.
> >   services: configuration: Use transducers within
> >     serialize-configuration.
> >   services: fstrim-service-type: Serialize with SRFI-171
> > transducers.
> >   doc: Rewrite define-configuration.
> >   services: configuration: Add serializer-options field.
> 
> I think these changes are OK on their own since they add some extra
> flexibility to the serialize-configuration procedure and address a
> TODO item.
I'm not sure whether serializer options really add much value.  You can
use functional programming to define serializers for you and pass those
options in a cleaner way IMHO.  The documentation should be updated as
the changes are made.  As for the switch to SRFI 171, I'm not sure
whether backwards compatibility with Guile 2.2 is a requirement
somewhere; if it isn't, that change is probably fine.

> >   services: configuration: New generic-ini module.
> >   services: configuration: Add some commonly used predicates.
> 
> IMO I'm afraid this might be somewhat short-sighted and would be
> better addressed directly in Guile by implementing SRFI-233, perhaps
> by doing some adaptations to the approach taken here.
Even if Guile implemented SRFI 233 now, I'm not sure we could use it
tomorrow.  And even once we can use SRFI 233, we can keep backwards-
compatibility be re-exporting things.  The question is how necessary it
will be for us to maintain our own INI format writer.  NetworkManager
is one use case, but perhaps we have others (perhaps even in the gnome
world – gdm maybe?)

> >   services: NetworkManager: Use define-configuration and generic-
> > ini.>   services: NetworkManager: Prefer package over network-
> > manager.
> >   services: NetworkManager: add log-configuration field.
> >   services: NetworkManager: Add extra-options field.
> 
> Naturally these are no longer relevant if this generic-ini module
> approach is abandoned.
I think we can still upgrade this to define-configuration without a
generic-ini, but see above.  That being said, we can certainly split
this into two series at the point you currently feel comfortable with
and work from there.

WDYT?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]