[bug#53676] [PATCH 4/5] services: pulseaudio: Add an extra-script-files configuration field.

[Maxim Cournoyer]

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Hi,
>
> Am Dienstag, dem 01.02.2022 um 15:27 -0500 schrieb Maxim Cournoyer:
>> [...]
>> > Is there a particular use-case for this (other than working around
>> > the location issue of default.pa et al.)?  If not, I'd rather make
>> > it s.t. our other files can more easily be stitched together in-
>> > place.
>> 
>> You mean, a use case for extra-script-files?  
> Yes.
>
>> Sorry, I missed something in the "make it s.t. our other [...]"; what
>> does "s.t." stands for?
> "such that" or "so that".  Pretty common among mathematicians, I think
> 🙃

Ah!

>> My use case is the one I documented in the manual; setting a default
>> card profile for example.  Also choosing the default sink and source
>> of a card; this can be done in client.conf but that doesn't get
>> reflected anywhere on the state of a running pulseaudio server it
>> seems, contrary to calling 'set-default-sink ...', which takes effect
>> server-side.
> And you can't do this inside default.pa, because ... ?

I could; but what I want is to *extend*, rather than *replace* the
default.pa script; the native PulseAudio mechanism to do so is to put
files under '/etc/default.pa.d'.  We could simply tell people to use
extra-special-file service to achieve that, but that's less discoverable
than having a convenient, documented field to do so :-).

>> > Also, assuming that we're using file-like objects here, I think we
>> > should use the store name minus prefix and hash for the file name. 
>> > E.g. if Alice adds soundblaster.pa, it'd make sense to label it
>> > soundblaster.pa, so that changes to snippet order don't mess up any
>> > configuration referring to those files.
>> 
>> I actually wanted to do that but decided against since there's no
>> clean API to retrieve the name of a G-Exp file-like object (it could
>> be done, currently, but it'd be messy and fragile, it seems).
>> 
>> But good observation, I wanted to document that the extra script
>> files are loaded in the order they are listed.
> Isn't that what "strip-store-file-name" from (guix build utils) does?
> (Let's ignore hard-coded hash length...)

'strip-store-file-name' would be able to get the name from the store item
(built derivation), but file-union takes a "two-element list where the
first element is the file name to use in the new directory, and the
second element is a gexp denoting the target file", e.g., before the
file-like object is built.  I don't see an easy way to make it work.

Thanks,

Maxim