ladish provide an ABI compatible lash infrastructure with some improvements. It have been out from years, and some software begun to support ladish instead of lash - see https://bugs.gentoo.org/932851 . It would be great to also have ladish in the tree, see bug https://bugs.gentoo.org/442916 with the ABI report. According to a discussion on #gentoo-dev-help the best solution is to implement a virtual. Reproducible: Always
Current list of the main tree's packages that depend on lash: ./media-plugins/calf/calf-0.90.3-r2.ebuild: lash? ( media-sound/lash ) ./media-plugins/calf/calf-9999.ebuild: lash? ( media-sound/lash ) ./media-sound/amsynth/amsynth-1.13.4.ebuild: lash? ( media-sound/lash ) ./media-sound/fluidsynth/fluidsynth-2.3.5.ebuild: lash? ( media-sound/lash[${MULTILIB_USEDEP}] ) ./media-sound/hydrogen/hydrogen-1.2.2-r1.ebuild: lash? ( media-sound/lash ) ./media-sound/hydrogen/hydrogen-9999.ebuild: lash? ( media-sound/lash ) ./media-sound/jack-keyboard/jack-keyboard-2.7.2-r1.ebuild: lash? ( media-sound/lash ) ./media-sound/jack-rack/jack-rack-1.4.8_rc1-r1.ebuild: lash? ( media-sound/lash:= ) ./media-sound/jack-smf-utils/jack-smf-utils-1.0-r1.ebuild: lash? ( media-sound/lash ) ./media-sound/seq24/seq24-0.9.3-r1.ebuild: lash? ( media-sound/lash ) ./media-sound/timemachine/timemachine-0.3.4.ebuild: lash? ( >=media-sound/lash-0.5 ) ./media-sound/vkeybd/vkeybd-0.1.18e.ebuild: lash? ( media-sound/lash:= )" ./media-sound/zynaddsubfx/zynaddsubfx-3.0.6-r3.ebuild: lash? ( media-sound/lash ) ./media-sound/zynaddsubfx/zynaddsubfx-3.0.6-r4.ebuild: lash? ( media-sound/lash )
Created attachment 897336 [details] proposed virtual/lash ebuild As lash and ladish cannot be installed at the same time, this create a blocking that I solve into that virtual with a 'ladish' USE flag. I find this more convenient for the user than to add that blocking into media-sound/[lash|ladish].
Created attachment 897337 [details] metadata.xml It copied metadata.xml from virtual/jack. I feel it is correct to do so, because lash/ladish are used mostly for serious or intensive audio work.
Created attachment 897346 [details] proposed virtual/lash ebuild v.2 I read the devman page about USE flags, and it is no reason to not have a default 'IUSE=+ladish"'. I find this to be adequate because on the long run, ladish will replace lash when ladish only software will be added into the tree.
Created attachment 897347 [details] metadata with ladish USE description Please correct my English if needed or better.
It is more we can say about ladish and that virtual. As explained here: https://github.com/jackaudio/jackaudio.github.com/wiki/Suggested-packaging-approach only one jack server implementation can be installed at a given time. But as a discussion with nedko on irc #ladi showed me, when ladish depend on jackd2[-classic dbus] it will work as, and be fully API compatible with lash. In order for ladish to provide its full functionality, and to be API compatible with lash, a new package must be provided, jackdbus https://github.com/LADI/jackdbus that depend on media-sound/jack2[-classic -dbus]. It is even one more alternative: to provide both media-sound/jackdbus and ladi-jack2 from https://github.com/LADI/jack2 That package can be named media-sound/ladi-jack2 or media-sound/jack2-ladi In that case, ladish that will depend on virtual-jack and jackdbus on ladi-jack. I am working on a PR for ladish and virtual/lash 3 questions: - I think it would be right to include at least media-sound/jackdbus into that PR, as it provide full ladish functionality. Should a bug report be made for that new package, or is it enough to mention it here and in the PR commit message? - I am willing to also include media-sound/ladi-jack2 into that PR, which will imply to modify virtual/jack. Is it OK to do so now, and what is the best name for it, media-sound/jack2-ladi (I prefer that as it's an alternative to jack2 and can be easier to find for users) or media-sound/ladi-jack2 (nedko prefer that)?
Either of media-sound/ladi-jack2 or media-sound/jack2-ladi is fine. I tend to use "ladi" as prefix upstream, but using suffix is no less valid, as the real point is to mark alternative version (fork). Using prefix nicely matches the organization/project arrangement in modern web git hosting software. The media-sound/jackdbus is useful for setups where virtual/jack is backed by JACK server implementations different from jack2. The history is that jackdbus code was created first for jack1 (media-sound/jack-audio-connection-kit) as fork. Then it was ported to jackdmp (a SMP reimplementation of jackd in C++) codebase by creating the JACK control.h API and its implementation in new library "libjackserver.so". The resulting jackdbus binary in jack2, while using libjackserver.so, and thus de-facto separated at code level, was still bundled as part of jack source tree, which provided the configure time selection of jackd vs jackdbus setups. Today, libjackserver.so is also available/installable for jack1 (in the ladi fork) and pipewire. While the pipewire implementation of jackserver.so is still barely functional, a new media-sound/jackdbus atom enables more options for gentoo users. https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/819
