berkeley-db: Build db_dump185 compatibility util

[trinitronx]

The --enable-dump185 Builds the db_dump185 utility, which can dump Berkeley DB 1.85 and 1.86 databases. MacOS and BSD variants such as FreeBSD still use this version in certain system files such as /private/etc/aliases.db /etc/pwd.db, /etc/spwd.db, /etc/login.conf.db and others.

See: https://docs.oracle.com/cd/E17275_01/html/programmer_reference/build_unix_conf.html#build_unix_conf

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing HOMEBREW_NO_INSTALL_FROM_API=1 brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

[github-actions]

Thanks for contributing to Homebrew! 🎉 It looks like you're having trouble with a CI failure. See our contribution guide for help. You may be most interested in the section on dealing with CI failures. You can find the CI logs in the Checks tab of your pull request.

[trinitronx]

Note: Just needs libdb-dev ^^{libdb1-compat} on Linux for db.h header file + libdb1.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[trinitronx]

@github-actions Bump

Working on other things at the moment... will get back around to this

[trinitronx]

@chenrui333: This is now ready for review! 🎉

[carlocab]

Thanks, a few comments/questions.

[carlocab]

It seems like a huge pain to install this on Linux. Can we just do it on macOS?

[trinitronx]

Can we just do it on macOS?

Possibly, although then it would not be in feature parity with the already built macOS binaries. From time to time, I find myself on Linux needing some BSD-specific tool (or vice versa). The idea was to keep things working the same across different OS for a better user experience. A big plus!

Also, I did spend a few days doing all the hard work already. 😅 🤷

It seems like a huge pain to install this on Linux.

While it might seem like this at first glance, the simpler-looking alternatives were either not supported ¹, or Debian-specific ^{(and hiding complexity)}. Plus, I figured the policy for Linuxbrew would be to keep things building independently without tying into system dependencies on one distro or another.

This avoids locking to Debian build tools, which would have the usual simpler-looking apt-get build-dep ..., apt-get source ..., debuild method ². Otherwise, just installing apt-get install libdb1-compat and building against system libs worked but then again only works on Debian-based distros and creates a build dependency on something outside Homebrew.

The usual method on Debian is to unpack the .orig.tar.gz and .debian.tar.xz files and just run debuild, which applies all the patches inside the unpacked debian/patches directory which came from the *.debian.tar.xz archive. We could have done that here with system commands and it would look cleaner, but then it would depend on Debian-specific build tools and increase the build dependencies needed.

Footnotes

1. At first, I tried using patch with apply %W [ ... ] nested inside the resource block for the debian source code, simlar to how mytop does with a top-level .debian.tar.xz Formula patch. However, nesting this to patch another resource didn't appear to be supported in the current Ruby Formulary DSL. Also, patch only expected a single patch via URL or possibly more via :DATA with an embedded __END__ section. Although, using that wouldn't be ideal because all patches are already from upstream and we'd need to then duplicate & maintain them in this Formula to use :DATA. Although it didn't work, it would've looked much simpler if we could nest them like:

   resource 'foo' do
     url '... source code tar.gz ...'
     ...
     patch do
       url '... debian.tar.xz with patches inside ...'
   
       apply %W[ ... list of files in debian/patches to apply ... ]
     end
   end
   

   ↩

2. While this might look simple, it hides complexity and also yields more build dependencies. For example: debuild internally applies the debian/patches via quilt push -a, runs dpkg-buildpackage and more, hiding all the complexity inside one command. Yet, again this uses more Debian-specific packaging tools internally which increases the build dependency list and locks it into only working on Debian-based distros. ↩

[carlocab]

I appreciate that you've done a lot of work here, but keeping this around just isn't very maintainable. Sorry!

If you need db_dump185 on Linux, I suggest hosting a version of this formula in your own tap.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[trinitronx]

@github-actions Bump

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[trinitronx]

@github-actions Bump

[MikeMcQuaid]

I agree with @carlocab. I'm 👍🏻 to doing this on macOS and 👎🏻 to doing it on Linux (until it's more like a 2-3 line diff)

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.