GNU bug report logs - #53676
[PATCH 0/5] *** PulseAudio service improvements ***

Previous Next

Full log

Message #68 received at 53676 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 53676 <at> debbugs.gnu.org
Subject: Re: [PATCH 4/5] services: pulseaudio: Add an extra-script-files
 configuration field.
Date: Wed, 02 Feb 2022 21:07:27 +0100

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.