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

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 1786 bytes --]

Liliana Marie Prikler schreef op do 24-03-2022 om 16:38 [+0100]:
> Am Donnerstag, dem 24.03.2022 um 16:05 +0100 schrieb Maxime Devos:
> > Liliana Marie Prikler schreef op do 24-03-2022 om 08:22 [+0100]:
> > > I agree that breaking up cycles is a good thing, but I disagree
> > > with some of the decisions you've made here.  For instance, I
> > > oppose the use of single-package modules, because those more often
> > > than not simply clutter the file system.
> > 
> > There are some other sound applications in (gnu packages audio)
> > and (gnu packages music), so maybe I can make a (gnu packages audio-
> > apps) module where 'audacity' and other applications like 'calf' can
> > reside?
> I'm not sure.  IIUC, audio should be for audio systems, codecs, etc.
> whereas music sounds like a particular niche containing music players
> etc.
> [...]

I'm not sure where the ‘I'm not sure’ comes from --- audacity is not an
audio system like pulseaudio or alsa, not a codec implementation like
libvorbis, and it is a sound player (and editor), so IIUC, audacity
does not fit into (gnu packages audio).

While it can be used for modifying and playing music, it is more
general than that, hence the suggestion of (gnu packages audio-apps)
(where some other packages can be moved to as well, maybe 'gnaural'?).

Though granted, it's difficult to make a strict distinction between
audio and music.

>   Perhaps the cycle could more appropriately been broken by moving
> stuff from music to audio?

(gnu packages music) is full of applications using gtk+ or gles or the
like.  Moving them to (gnu packages audio) would make (gnu packages
audio) depend on (gnu packages gtk) and friends, which seems counter-
productive to me.

Greetings,
Maxime.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]