[bug#53676] [PATCH v2 2/4] gnu: pulseaudio: Graft to adjust configuration.

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Liliana,

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

> Am Donnerstag, dem 24.02.2022 um 11:38 -0500 schrieb Maxim Cournoyer:
>> * gnu/packages/pulseaudio.scm (pulseaudio/fixed): New variable.
>> (pulseaudio)[replacement]: Graft package with it.

[...]

>> +(define pulseaudio/fixed
>> +  (package
>> +    (inherit pulseaudio)
>> +    (arguments
>> +     (substitute-keyword-arguments (package-arguments pulseaudio)
>> +       ((#:phases phases)
>> +        `(modify-phases ,phases
>> +           (add-after 'unpack 'customize-default-script
>> +             (lambda _
>> +               (substitute* "src/daemon/default.pa.in"
>> +                 (("^\\.include.*default.pa.d.*" anchor)
>> +                  (string-append
>> +                   ;; Honor PulseAudio script extensions found under
>> +                   ;; /etc/pulse/default.pa.d.
>> +                   anchor ".include
>> /etc/pulse/default.pa.d\n")))))))))))
>> +
> I still think it'd be wiser to do this inside the code that generates
> the configuration when we do fill /etc/pulse/default.pa.d given that
> there's stuff to source.  At the very least, we'd avoid a graft for the
> moment, but we'd also avoid some "lol, just source anything" scenarios.

Thank you for your continued feedback.  The reason I prefer this simple
substitution to a conditional one is two-fold:

1. It avoids two actors potentially touching the default 'script-file'
(the pulseaudio-service-type code as well as the user), which could be
unwieldy (do we plug the default.pa.d after their changes to ensure it
is there, or before, which means it'd potentially be erased?).  Having
it part of the shipped default.pa file makes this simpler to reason
with.

2. It allows foreign distribution users to keep their custom user script
working even when they use our pulseaudio package (it makes our
pulseaudio package behave as intended by upstream).

I wouldn't mind using a feature branch to get the < 2k dependent
packages rebuilt as suggested by Leo, if you think that's preferable.

Thanks,

Maxim