On 2023-08-13 13:28, 宋文武 wrote: > Ludovic Courtès writes: > >> [...] >> >> This patch lets us map System services to Home and uses the new >> mechanism for three services: mcron, dicod, and syncthing. >> >> services: dicod: Remove Shepherd < 0.9.0 compatibility layer. >> services: dicod: Pre-build the GCIDE index. >> services: syncthing: Use 'match-record'. >> services: Define 'for-home'. >> home: services: Support mapping of System services to Home services. >> home: services: mcron: Define as a mapping of the system service. >> home: services: Add dicod. >> home: services: Add Syncthing. > > I didn't test them, but those changes look good to me! Hi Ludovic, 宋文武! Sorry for comming late to the party, I saw this message only a week ago and didn't have time to make an extensive reply yet, so I will share my quick thought on the most problematic part and maybe later will formulate others thoughts in more details. define-service-type-mapping looks imperative and potentially very problematic. Collecting those values in unknown order and applying this implicit transformation making a good room for foot shooting. Imagine someone would like to use his own (let's say) shepherd home service implementation and will add this to one of the source files of their channel: --8<---------------cut here---------------start------------->8--- (define-service-type-mapping shepherd-root-service-type => my-home-shepherd-service-type) --8<---------------cut here---------------end--------------->8--- What happens if somebody will use his channel just for getting some package? Very likely it would break the build or in the worst case it will build with unexpected service implementation under the hood. I had [1][2] and still have concerns about macros and records composability and reusability. I personally don't like excessive usage of them in general. By adding more macros, already quite complex guix services mechanism becomes even more harder to learn, inspect, reason about and work with. In addition to that it has a major technical issue mentioned above. I'm strongly against this change and would suggest to revert it. I hope it doesn't sound rude and I'm really thankful for your work on this, but I just think it's not the right solution, at least yet, in its current form. [1]: https://yhetil.org/guix-devel/878rvp1deg.fsf@trop.in/T/#u [2]: https://yhetil.org/87ild88kax.fsf@trop.in -- Best regards, Andrew Tropin