Deprecated formulae with dependents

[carlocab]

A number of formulae were deprecated despite having dependents. This goes against our deprecation policy, and these formulae were undeprecated in order to enable merging Homebrew/brew#12770.

We should decide what to do about these formulae and their dependents:

• [ ] cmu-sphinxbase
• [x] dep -- #111241
• [ ] docker-machine - https://github.com/Homebrew/homebrew-core/pull/107037
• [ ] glide
• [ ] govendor
• [ ] guile@2
• [ ] ilmbase
• [x] [email protected] - #110163
• [ ] jam
• [ ] libelf - replace dependents with #104303
• [ ] [email protected]
• [ ] mpfi
• [ ] openexr@2
• [x] sdl - #111081
• [ ] sdl_image
• [ ] sdl_mixer
• [ ] sdl_net
• [ ] sdl_sound
• [ ] sdl_ttf
• [ ] tbb@2020 - next release of osrm-backend should support tbb. Can re-deprecate tbb@2020 afterward
• [x] [email protected] - #107657
• [ ] ykclient - https://github.com/Yubico/yubico-pam/issues/242

[carlocab]

As noted in previous PRs, sdl dependents can probably be made to use sdl2 using sdl12-compat. [email protected] dependents may be able to use luajit.

For the rest, I suggest investigating whether the dependency can be removed. If not, we should file issues upstream to ask about their plans for the deprecated dependency.

We should prioritise those formulae that have outstanding CVEs or are causing us problems in CI.

[carlocab]

[email protected] has gcc@5 as a dependent. We can deprecate both when we migrate to a newer bottling distro. See Homebrew/brew#13619.

[carlocab]

I left bazaar out of the list above. It can be deprecated once https://github.com/Homebrew/brew/pull/13617 is merged and lands in a release tag.

[danielnachun]

A few things I've found so far:

• cmu-sphinxbase - cmu-pocketsphinx has moved to GitHub (https://github.com/cmusphinx/pocketsphinx) and SphinxBase is now integrated into it. So cmu-pocketsphinx should be updated not to depend on cmu-sphinxbase and at that point cmu-sphinxbase will have no dependents.
• dep - devd is the only undeprecated dependent and @Bo98 opened an issue more than year ago asking about Go module support which remains unanswered: https://github.com/cortesi/devd/issues/115. It's probably time to deprecated devd.
• docker-machine - Given that docker-machine is deprecated I don't see any way for its docker-machine-* dependent to be supported. So they all probably should be deprecated.
• glide - has two undeprecated dependents jabba and textql. textql has had an unanswered issue open for more than a year about Go module support: https://github.com/dinedal/textql/issues/131. It looks like jabba may have added Go module support in upstream commits: https://github.com/shyiko/jabba/commit/7b9e621692810876a6b9363c6b6af7ea446ae39f.
• govendor - dockviz is the only undeprecated dependent. There is an open issue about Go module support: https://github.com/justone/dockviz/issues/49. But it doesn't seem like anything has been done yet to add support.
• guile@2 - used by lilypond which is definitely actively developed. It's unclear if works with Guile 3 but it may be worth trying.
• ilmbase - has two dependents ctl and field3d- development appears stalled for both so they should probably just be deprecated. jam - has two build dependents argyll-cms and lincity-ng. We should contact both upstreams asking if they plan to migrate to a different build system.
• libelf - has two dependents avrdude and dynamips. We've already migrated both of these to elfutils on Linux but we can't do so on macOS because elfutils is Linux-only.
• mpfi - there is a GitHub maintenance fork now which might be a suitable substitute. It could be vendored as a resource for sollya, its only dependent, instead of being maintained as a separate formula.
• openexr@2 - needed for ctl - see above comment for ilmbase.
• tbb@2020 - has one dependent osrm-backend which is actively developed. There is an open issue about this failing to build with newer TBB: https://github.com/Project-OSRM/osrm-backend/issues/6181
• [email protected] - has two dependents gdcm and itk - both are actively maintained and we should see if they work with newer vtk. If not we should open upstream issues.

[SMillerDev]

For docker-machine I believe Gitlab took over development.

[alebcay]

Just tried lilypond with guile (3.x), looks like it does not search for/consider 3.x versions:

[...]
checking for guile-1.8 >= 1.8.2... no
checking for guile-2.2 >= 2.2.0... no
checking libguile18.h usability... no
checking libguile18.h presence... no
checking for libguile18.h... no
[...]
ERROR: Please install required programs:  guile-devel >= 1.8

[cho-m]

I remember looking into lilypond and, as I recall, support was added in HEAD (and maybe unstable version). We would need to wait for stable version with changes. EDIT: What I previously saw was https://gitlab.com/lilypond/lilypond/-/merge_requests/1230 but haven't checked if it works.

I tried re-enabling/updating mpfi in #98522, but it had segfaulted on make check. Didn't really look into reason.

My libelf migration plan was elftoolchain (#104303) though not sure of actual compatibility.

[email protected] - gdcm issue was opened a while back (https://sourceforge.net/p/gdcm/bugs/509/). We could just disable VTK support again.

[SMillerDev]

I don't think docker-machine is actually resolved now. It just went from unsupported upstream to deprecated upstream.

[carlocab]

Oh, I was under the impression that the GitLab fork was under development. Unticked.

[SMillerDev]

It is, until they work out how to drop it. So it's still not a long term solution unfortunately.

[nwhetsell]

@cho-m The latest (but unstable) version of LilyPond can now be built with Guile 3. If it’s any help, I have this working over at

https://github.com/nwhetsell/homebrew-lilypond/blob/master/Formula/lilypond-unstable.rb

I’m not sure when LilyPond will release a new stable version, unfortunately; I’d say Feb 2023 if I had to guess.

[danielnachun]

@cho-m The latest (but unstable) version of LilyPond can now be built with Guile 3. If it’s any help, I have this working over at

https://github.com/nwhetsell/homebrew-lilypond/blob/master/Formula/lilypond-unstable.rb

I’m not sure when LilyPond will release a new stable version, unfortunately; I’d say Feb 2023 if I had to guess.

Since this "unstable" release is properly tagged and obeys semantic versioning, I'm inclined to say we should just update our formula to that version, and maybe even start using those instead. lilypond has no dependents it cannot break any other formulae. It seems that the upstream definition of "stable" may be more conservative than what we would consider stable.

[danielnachun]

It is, until they work out how to drop it. So it's still not a long term solution unfortunately.

I think we should just deprecate docker-machine and its dependents in this case. It would be better to do this now so users get a heads up that they are relying on an unmaintained product and need to start switching over. From what I understand there are a number of other actively maintained alternatives that are not drop in replacements but can do the same things.

[SMillerDev]

I think we can set a disable date for docker-machine. But as a user of docker-machine there's only two alternatives that I know of, and both aren't great.

• Docker Desktop: proprietary and doesn't allow other vrtualisation backends.

• podman machine: open source, doesn't allow other backends than QEMU. Not as easy to set up as docker-machine.

Unfortunately I found out that docker-machine doesn't run out of the box on M1 either (needs special configuration to run arm machines), so disabling it at a future date makes sense to me.

[alebcay]

I use lima after Docker Desktop changed their licensing. It runs with a QEMU backend and is fairly simple to set up (2-3 commands). I believe it also works on M1 too.

[carlocab]

I use lima after Docker Desktop changed their licensing.

Same. It's part of why I added the bit about lima to our contributing guide.

[justone]

I updated dockviz to use go modules. Sorry for the delay.

[cho-m]

cmu-pocketsphinx has a new release now. Can deprecate cmu-sphinxbase after we update that.

lilypond is on RCs with new stable release planned for this month. Can deprecate guile@2 once that is available.

[cho-m]

I wonder if we should just deprecate dosbox formula.

We still have a Cask for macOS users - https://formulae.brew.sh/cask/dosbox#default

And SDL2 supported forks:

• https://formulae.brew.sh/formula/dosbox-staging#default
• https://formulae.brew.sh/formula/dosbox-x#default

Only issue is the dosbox formula is still somewhat popular:

==> Analytics
install: 342 (30 days), 1,226 (90 days), 4,280 (365 days)
install-on-request: 359 (30 days), 1,241 (90 days), 4,291 (365 days)
build-error: 0 (30 days)

Though a deprecation message with recommended alternatives could help steer some users away.

---

Fedora is an example repository that dropped support for dosbox and recommend dosbox-staging to its users - https://src.fedoraproject.org/rpms/dosbox

[cho-m]

docker-machine GitLab plan ref https://gitlab.com/groups/gitlab-org/-/epics/2502

• We are fully supporting the GitLab maintained Docker Machine fork for autoscaling runner on VM's on the significant public providers at a minimum through FY24 Q4.

[chrisfinazzo]

This is not exactly a deprecation, but is there a replacement for pycparser as a dependent of ocrmypdf? brew doctor reports the following:

Warning: Some installed kegs have no formulae!
This means they were either deleted or installed manually.
You should find replacements for the following formulae:
  pycparser
Chris in [~] % brew uninstall pycparser
Error: Refusing to uninstall /usr/local/Cellar/pycparser/2.21
because it is required by ocrmypdf, which is currently installed.
You can override this and force removal with:
  brew uninstall --ignore-dependencies pycparser

[carlocab]

You shouldn't be seeing that message, since pycparser is an existing, non-deprecated formula.

Try doing

brew update
brew reinstall pycparser

If that doesn't help, try making a post at the discussion page (not here), and include the full output of brew config, brew doctor and brew info pycparser.

[IgorKha]

Hello, couldn't find where to post, but Minicom doesn't work at high data rates(1500000). This has been fixed in the latest version https://salsa.debian.org/minicom-team/minicom/-/releases/2.9 Please let me know where I can post a request to update this package?

[cho-m]

Going to close this as complete given we have finished all actionable tasks.

libelf is going to take months/years to get a resolution on as there is no ideal alternative right now on macOS (elfutils requires a lot of hacks to build on macOS, elftoolchain is still buggy & upstream is very slow to release, and discussion with dependent upstreams are mainly around bundling the library which isn't much better).