[Devel-en] 2019.1 - Status of packages in the Sound group [WARNING - long message]

[Giovanni Mariani]

Hi all...

In the last few years I more or less worked as voluntary maintainer for 
the packages in the Sound group.

The long time passed since our old 2016.1 distro release caused us 
remain rather behind regarding the packages we are providing in our 
repositories. Particularly a bunch of fundamental libraries arrived to 
their EOL:
Qt4, KDE4 and Gtk2; and obviously there are a few packages depending 
upon the now deprecated or dead libraries.
So I settled to do an audit of all the Sound srpm packages to see what 
of them are in the situation described above and, while at it, I also 
looked for packages having or not having updates ready (new releases or 
interesting upstream patches) and for packages not being updated 
upstream since a long time (sometime good candidates for a removal)

Now I would like to share what I found, because I feel that it could be 
useful in giving shape at the next distro release.

So: if my counts are right, we have a total of 461 srpm packages in the
Sound group.
Of them:	58 have a dead URL
		198 + 1 (unsure) have no updates since >= 3 years
		107 have a new release upstream, ready to be picked
		54 have updates (patches in git or whatever source
		control system it's used upstream)


And here is an hopefully complete list of the issues I found, with some 
proposals to solve them.

* Srpm packages depending upon Qt4 libs (and no qt5 port)
**********************************************************
easymp3gain		(last update: 2013)
ermixer			(last update: 2003)
fretscale		(last update: 2012)
kradio			see below
kradioripper	see below
kstreamripper	see below
lastfm-desktop
pianobooster	(there is a new release supporting Qt5)
picard		(there is a new release supporting Qt5 and python3)
qtradio			(last update: 2014)
tomahawk	(there is a new pre-release supporting Qt5)
tutka?
As rule of thumb, I would drop all the packages requiring an 
unmaintained library, particularly when it did not have upstream updates 
since a few years: it is unlikely to get adapted to the newer libraries.

*Proposal*: drop all the packages listed above, but pianobooster, 
picard, tomawhak and perhaps lastfm-desktop and tutka.


*Srpm packages depending upon KDE4 libs (and no plasma5 port)
**************************************************************
amarok			(there is a new pre-release supporting KDE5)
audex			(last update: 2017)
audiokonverter		(there is a new release supporting KDE5)
audiokonverter-restricted	(there is a new release supporting KDE5)
kmid2			(replaced by new qt5-only dmidplayer)
kmidimon		(there is a new release supporting Qt5)
konvertible		(last update: 2010)
kradio			(last update: 2017)
kradioripper		(replaced by kstreamripper)
kstreamripper		[already dropped ATM]
As rule of thumb, I would drop all the packages requiring an 
unmaintained library, particularly when it did not have upstream updates 
since a few years: it is unlikely to get adapted to the newer libraries.

*Proposal*: drop all the packages listed above, but audiokonverter and 
amarok.
For audiokonverter, see if it's best upgrading the existing package to 
support KDE5 or provide a new plasma5-audiokonverter one (upstream 
sources allow both option); I have a WIP plasma5-audiokonverter package 
locally.


*Srpm packages depending upon Gtk2 libs (and no gtk3 port)
***********************************************************
ario
audacity?
aumix
autozen
calf
easymp3gain		(last update: 2013)
easytag			(last update: 2015 - replaced by easytag24)
extace			(last update: 2008)
foo-yc20	(this won't build against our faust 2.x.x - drop)
galan			(last update: 2007)
ghostess
gjay			(last update: 2016)
gmpc (11.8.16)
gmpc-lastfm (0.20.0) (this could not work with the current gmpc - drop)
gmpc-libnotify (11.8.16)
gmpc-lyrics	(11.8.16)
gmpc-magnatune (11.8.16)
gmpc-mdcover (0.20.0) (this could not work with the current gmpc - drop)
gmpc-mserver (0.20.0) (this could not work with the current gmpc - drop)
gmpc-shout (0.20.0)   (this could not work with the current gmpc - drop)
gmpc-wikipedia (11.8.16)
gmusicbrowser
gnome-alsamixer		(last update: 2017)
gnormalize		(last update: 2012)
gnuitar			(last update: 2005)
grip
gst123			(last update: 2017)
gtkguitune
gwc
gxtuner			(last update: 2013)
hexter
hinetradio		(last update: 2012)
invada-studio-plugins-lv2
jack_capture		(last update: 2017)
jack-rack		(last update: 2014)
jackeq			(last update: 2012)
jamin			(last update: 2013)
lame	(gtk2 is needed only for the mp3x gui program, not for the library)
lash			(last update: 2009)
lingot			(there is a new release supporting gtk3)
mhwaveedit		(last update: 2018)
midicontroller?		(last update: 2004)
nekobee
nekostring		(last update: 2014)
newtonator		(last update: 2012)
nted			(last update: 2014)
openav-sorcer-lv2
pavumeter?		(last update: 2007)
phasex			(last update: 2013)
songwrite2		(replaced by songwrite3)
songwrite3?		(last update: 2017)
timemachine
wavbreaker
whysynth		(last update: 2017)
wsynth-dssi
xhippo			no more developed
xsynth-dssi		(last update: 2010)
zita-rev1 	(there is a new release using cairo, rather than
		directly gtk2)
As rule of thumb, I would drop all the packages requiring an 
unmaintained library, particularly when it did not have upstream updates 
since a few years: it is unlikely to get adapted to the newer libraries. 
But for the GTk2 stuff, this would mean dropping some "big stuff" (eg: 
audacity, calf, gmpc, nted...), while they could be ported to gtk3 in a 
near future, because upstream is still active.

*Proposal*: keep the packages having updates for sure; drop for sure all 
the packages not updated since long time (> 3 years?), because it's 
unlikely they will have major changes in the next future.
To be decided for the others: keeping the will force us to continue to 
keep around the gtk2 libraries, with all the maintenance work this 
means; dropping those packages too fast, while upstream is still more or 
less active, could force us to restore in a near future some of the 
packages we dropped today.


While verifying the packages in the Sound Group, I also found 3 other 
types of issues with the srpm packages in Sound

* Some Packages seem to be placed in the wrong Group:
******************************************************
diaspora		is a game
jack			is in System/Servers, but could be Sound
libtunepimp		is in System/libraries, but really should be
			Sound (as for libmusicbrainz)
linthesia		is a game
portaudio	 is in System/libraries, but really should be Sound
portmidi	 is in System/libraries, but really should be Sound
pulseaudio		is in System/Servers, but could be Sound
python-livestreamer	should go in Video, given the Description
python3-livestreamer	should go in Video, given the Description
taglib			is in File tools, but really should be Sound
			(used only for tagging sound files)
xine-lib	is in System/libraries, but should be Sound or Video
Near all the cases listed above are libraries working with sound files 
(xine-lib also video files). Then the "System/libraries" Group is OK for 
the produced rpm packages, but not for the srpm ones.
For jack and pulseaudio, I think the proposed change is OK if we want to 
diffrentiate among the variuos system servers we provide (sound, video, 
print...); as for the library case, the produced rpms will still belong 
to "system/servers", while the srpm could tell what type of server is.

*Proposal*: change all the above srpms as proposed (with the possible 
exception of: jack and pulseaudio).


*There are srpm packages that are actually replaced by other more recent 
packages that we already have (new package name):
************************************************************************
celt051			(celt)
easytag			(easytag24)
gmpc-extraplaylist	(gmpc)
gmpc-osd		(gmpc)
jconvolver-reverbs	(jconvolver)
kmid2			(qmidplayer)
libtunepimp		(libmusicbrainz5?)
songwrite2		(songwrite3)
speex			(opus)
sphinx2			(sphinx3)
sphinx3			(sphinx4 - not provided yet in ROSA)
SpiralLoops		(spiralsynthmodular)
SpiralSynth		(spiralsynthmodular)

*Proposal*: All of them should be dropped (with the possible exception 
of sphinx3, until we provide sphinx4).


* There are also old and not updated packages of dubious usefulness:
*********************************************************************
celt051		was provided for compatibility when we switched to celt
		0.7.x+: still needed?
festvox-suopuhe-lj	are we interested in finnish language?
festvox-suopuhe-mv	are we interested in finnish language?
pvc		won't build under 2019.1 toolchain and no updates since
		2012
rio500	the hardware is 20 years old and perhaps no more relevant
rioutil	the hardware is 20 years old and perhaps no more relevant

*Proposal*: drop all.

My plan is to implement the above proposals and to start updating the 
packages having new stuff upstream. But, being only a volunteer, I would 
like having some approval from the main stakeholders of the 
distribution, at least for the proposals...

Cheers.
GvM