[bug#60014] [PATCH] activation: make install-special-file match against pairs as well.

[mirai]

On 2022-12-12 20:34, Josselin Poiret wrote:
> Hi Bruno, 
> 
> Is this patch related to some specific problem you're running into?  I
> personally would prefer keeping the special file interface as-is, and
> not mix two different kinds of entries: lists with 2 elements, and
> pairs.  That would avoid having to manage even more edge-cases down the
> line if some more processing is needed.

I'm writing a service definition that uses a special-files-service-type 
service-extension.
The documentation for it says:
--8<---------------cut here---------------start------------->8---
The value associated with special-files-service-type services must be a list of 
tuples where the first element is the “special file” and the second element is 
its target. 
--8<---------------cut here---------------end--------------->8---

I assume a pair is a reasonable interpretation of 'tuples' in this context, so 
I proceeded to serialize the fields with:
--8<---------------cut here---------------start------------->8---
(cons "filename here" (mixed-text-file "filename" contents ...))
--8<---------------cut here---------------end--------------->8---

Which I think is the natural way of doing it. (and communicates the intent, a 
pair with a path and a file-like object.)

Of course, (list "path" file-like-obj) works as well but imo the pair is 
clearer in purpose.
(what meaning would the third element and so on have, if ever present?)
This I found out the hard way by getting strange errors until I looked into 
what happens behind
`special-files-service-type' and realizing that only lists were accepted.

The mixing of cases is unfortunate (it should have been pairs from the start) 
but preserves
compatibility with existing syntax.