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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Dienstag, dem 01.02.2022 um 22:44 -0500 schrieb Maxim Cournoyer:
> > > 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 :-).
I still don't understand what the big difference would be when it comes
to Guix.  You can already split your configuration over several modules
and include the bits you want, it doesn't particularly have to be the
way pulseaudio hacks around the lack of such functionality in
traditional distros.

Again, I might be missing a use case in which pulseaudio's style makes
more sense, but there appears little reason to create these directories
simply for the sake of it.

> > > > 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.
For the record, I do think we'd like to use file-like objects here, not
raw gexps.  If that fails, why not expose the name to gexp mapping
completely?  I don't know why you'd want to take away that control.