[bug#54539] [PATCH 0/6] Start breaking up import cycles

[Liliana Marie Prikler]

Am Freitag, dem 25.03.2022 um 15:12 +0100 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op vr 25-03-2022 om 12:47 [+0100]:
> > That's the status quo (through gnaural and audacity for example). 
> > To make a more educated guess, which cycle do we aim to address
> > here? 
> > Is there a meaningful cut that can be made (e.g. the offending
> > packages are all "audio editors", "audio synthesizers", etc.) or do
> > we have to separate good and bad based on their inputs?
> 
> Some cycles:
> 
> (gnu packages pulseaudio) -> (gnu packages audio) -> (gnu packages
> gtk)
> /(gnu packages qt)-> (gnu packages pulseaudio) + the world
> 
> (gnu packages pulseaudio) -> (gnu packages audio) -> (gnu packages
> webkit) -> (gnu packages gstreamer) + the world -> (gnu packages
> pulseaudio) + the world
> 
> Suggested cut: audio libraries like flac, libogg, libvorbis, opus,
> wildmidi, vo-aacenc, tinyalsa ... can go in (gnu packages audio),
> other things go somewhere else, especially if they need expensive
> imports.
Hmm, is it all codecs?  In that case, I'd suggest making a smaller (gnu
packages audio-codecs), that can be used by (gnu packages audio-
systems) [including (tiny)alsa, pulseaudio, jack, ...] that can be used
by the rest of the world.  Having that, we could move "the rest" into
audio-xyz (or let it simply remain "audio").  Would that be actionable?

(Note: There might still be debate w.r.t. the above split when
considering synthesizers, as they are technically not codecs, but we
still need to distinguish between low-level synths like fluidsynth and
wildmidi vs. full-on sound stations.)

(Note2: Of course, this assumes that neither audio-codecs nor audio-
systems will ever need to import any of the rust stuff.  *sigh*)


Cheers