[Slackbuilds-users] jack migration: round in the chamber, safety off

[B Watson]

To all maintainers and users of JACK-related builds:

I've pushed/submitted everything for the upcoming change. For the most
part, this just involved editing .info, README, and sometimes slack-desc
to replace "jack-audio-connection-kit" with "jack". I test-built most of
the modified scripts, but not the ones with really long/deep dependency
chains, and I didn't test-run most of the software against the new jack
package (just verified it builds).

The original plan was to pull the trigger (do a public update) today,
Sunday, but I've decided to wait until the next regular public update,
meaning it will go into effect Saturday night or Sunday morning. This
gives some extra time for testing.

Purpose of the migration:

The rest of the Linux audio world long ago moved from JACK1 to JACK2[1]
as the default version of jack. New software is being developed and tested
with JACK2, and audio-oriented distributions such as Ubuntu Studio have
long since switched to using JACK2 by default. Also, JACK1 doesn't take
much advantage of multiple cores[2], whereas JACK2 was designed from
the ground up to be multithreaded. The JACK developers still release
minor updates for JACK1, but have advised me that "everyone" should be
using JACK2 now. So from now on, the default JACK implementation on SBo
is going to be JACK2.

Result of the migration:

- The old jack-audio-connection-kit has been renamed to jack1. [3]

- The old jack2 has been renamed to jack.

- Everything that used to depend on jack-audio-connection-kit (either
  in REQUIRES or optional in the README) now depends on jack.

- Nobody will be allowed to use jack1 as a required dependency for
  new builds. If it's something that really does only work with jack1
  and not jack (aka JACK2), please contact me or one of the other SBo
  admins. Either we'll fix it so it builds, or make an exception to the
  "no jack1" policy.

- You still won't be able to install JACK1 and JACK2 on the same Slackware
  system. This is unlikely to change, unless someone comes up with a
  *really* compelling reason why it's desirable.

Users:

You won't have to worry about this until the next public update. At that
point, you'll want to remove jack-audio-connection-kit and/or jack2,
and build/install jack. You shouldn't install jack1. Your jack-using
applications shouldn't require a rebuild (there might be one or two
exceptions to this, but so far I haven't run into any).

If you don't want to mess with it at all, you can just leave things
as-is on your system. But if you do, sbopkg and/or sbotools won't notify
you of updates to jack, when they happen (because you won't have jack
installed). sbotools might also complain that a required dependency
(jack) isn't installed.

Maintainers:

If you haven't tested your builds against jack2 yet,
or if you want to make sure I haven't broken anything, you should
download the new jack SlackBuild from here:

http://urchlay.naptime.net/~urchlay/src/jack.tar.gz

Get rid of existing jack packages:

# removepkg jack-audio-connection-kit
# removepkg jack2

...and then checkout my git branch:

$ git clone git://git.slackbuilds.org/slackbuilds.git  # if you don't
already use git
$ cd slackbuilds
$ git checkout origin/urchlay

...and add the new jack.tar.gz to the checkout:

$ cd audio ; tar xvf /path/where/you/saved jack.tar.gz
$ rm -rf jack-audio-connection-kit jack2 # to be on the safe side

Now you can build the new jack, install it, and start building and testing
your own builds that use jack. If you run into trouble, please let us know
(replying to this email would be a good start).

You could also do all of the above using sbopkg (I think; I don't use
it often enough to be able to write directions for it).

Notes:

[1] JACK1 and JACK2 aren't two versions of the same codebase.
    They are different implementations of the JACK specification.

[2] In 2020, even computers salvaged from dumpsters are likely to have
    multiple cores...

[3] I had considered calling it "jack1-legacy" but I've been persuaded
    that this would be premature.