databases/ldb28 2.8.2_4

database/ldb*: fix lmdb0 brekage

Reported by:	pkg-fallout
Sponsored by:	Klara, Inc.

databases/lmdb: allow to install both 0.x and 1.x together

LMDB 1.0 and the legacy 0.9 ABI cannot be mixed, the datanase format are
incompatibles as well.

Rename or relocate everything databases/lmdb0 installs so that it no
longer overlaps with databases/lmdb:
- the utilities are now mdb_copy0, mdb_dump0, mdb_load0 and mdb_stat0
- the header is include/lmdb0/lmdb.h
- the linker name is liblmdb0.so, the shared object keeps its ABI name
  liblmdb.so.0 so already linked programs are unaffected
- the pkg-config file is lmdb0.pc

A compatibility prefix holding the previous layout is also installed
under ${PREFIX}/lmdb0/ (include/, lib/ and libdata/pkgconfig/) so that
build systems which expect to find lmdb.h and -llmdb relative to a
single directory only need a path change.

Now all ports should migrate to lmdb 1.X and use the lmdb 0.9 port to ease
in the migration path, lmdb, the lmdb 0.x is supposed to get removed at
some point.

Approved by:	mat (portmgr)
Reviewed by:	mat
Differential Revision:	https://reviews.freebsd.org/D60741

*: Fix dependency on lmdb0

databases/lmdb0: Add port for LMDB 0.9.x legacy ABI

LMDB 1.0 introduced an incompatible on-disk format change and subtle
API breakage: applications that compiled cleanly against 1.0 headers
could fail silently at run time. Known affected ports include dns/knot3,
mail/bogofilter, and mail/postfix; the postfix issue has been confirmed
upstream. Linux distributions such as Arch Linux have observed the same
breakage. Samba can also be affected in certain configurations.

Because the regression is not detectable in an -exp build run -- the
postfix failure only manifests at run time, and bogofilter was caught
only because post-build self-tests happen to exercise this path -- we
cannot rely on package builds to validate the 1.0 upgrade.

This commit introduces databases/lmdb0 as a holding port for the 0.9.35
release, pinned to the 0.x branch with PORTSCOUT=limit:^0. and mutually
conflicting with databases/lmdb, which retains 1.0. The two packages
cannot be installed simultaneously, but having lmdb0 available means:

* Ports known to require the 0.9 ABI can declare an explicit dependency
  on databases/lmdb0 until they are validated against 1.0.
* Users with existing databases in the 0.9 format can still access the
  mdb_dump and mdb_load utilities to migrate data before upgrading.
* The package conflict prevents accidental mixing.

All 50 direct dependents of databases/lmdb are redirected to
databases/lmdb0 for now with a PORTREVISION bump, effectively restoring
the tree to the state prior to the LMDB 1.0 update. Once all dependent
ports are validated against LMDB 1.0, they will be moved back to
databases/lmdb and databases/lmdb0 will be removed.

PR:             ports/296530

all: drop support for FreeBSD 13, mips and risc64sf

Reviewed by:            many (*)
Differential Revision:  https://reviews.freebsd.org/D55624
Differential Revision:  https://reviews.freebsd.org/D55642 (merged in from bofh)

many (*)
  acm arrowd brooks cmt dch decke dinoex eduardo fluffy fuz gahr garga
  jbeich joerg jrm kai kenrap martymac matthew mfechner michaelo mizhka
  nobutaka pkubaj se tagattie thj

  Anton Saietskii
  GenericRikka
  Gert Doering
  Jan Bramkamp
  Oleh Hushchenkov
  Oleksandr Kryvulia
  Ralf van der Enden
  Yamagi

  desktop kde python tcltk office

python.mk: rename PYTHON_EXT_SUFFIX to PYTHON_TAG, document, etc

EXT_SUFFIX, according to PEP 3149, refers to the full tag and
extension for compiled extension module objects, eg .cpython-311.so,
.cpython-313t.so, etc. We do not use the correct semantic meaning,
and this usage becomes ambiguous and confusing when tags do not
match between bytecode and compiled extension module objects.

Rename our PYTHON_EXT_SUFFIX to PYTHON_TAG to align with PEP 3147's
specification of a magic tag, which consists of implementation name
and shorthand version only. This is meant for bytecode and other
files containing this tag in their filename that do not depend on
a specific Python ABI for the same version. Chase all existing
consumers.

Introduce PYTHON_SOABI to align with PEP 3149's specification of a
tag, which consists of implementation name, shorthand version and
any ABI flags present (this and PYTHON_TAG are identical without
ABI flags). This is meant for compiled extension module objects and
other files that depend on a specific Python ABI for the same
version.

Add documentation for these variables that our PYTHON_EXT_SUFFIX
never had.

PR: 274671
Event: Kitchener-Waterloo Hackathon 202506

*/*: Rework manpages handling in Samba-related ports

* Remove outdated, incorrect, precompiled manpages from ${FILESDIR}/files/man.
* Properly disable manpages generation since XSLTPROC was set to true(1) WAF
  always assumed xsltproc(1) to work and if any automatic dependency pulled in
  textproc/docbook-xsl, manpages were generated even if explicitly disabled.

Approved by:	jrm (mentor)
Differential Revision:	https://reviews.freebsd.org/D49327

databases/ldb28: Update to 2.8.2

Necessary to update net/samba419 to 4.19.9.

Reviewed by:	0mp
Differential Revision:	https://reviews.freebsd.org/D47182

*/*: Let samba@ maintain ldb, tdb, talloc, tevent, and Samba

PR:		280556
Approved by:	portmgr

databases/ldb28: Add a new version of ldb

This port is based on ldb25. The changes are:

- Fix checks for Python support

  The bsd.port.pre.mk was included too early and USES=python wasn't
  processed as expected. As a result, the checks for Python support were
  broken.

- Switch from waf to configure and make.

  Upstream wants us to do it this way. Otherwise, the build system
  produces the following error message:

  > ===>  Configuring for ldb28-2.8.1
  > PYTHONHASHSEED=1 missing! Don't use waf directly, use ./configure and make!

  So, set HAS_CONFIGURE and BINARY_ALIAS to make the port build without
  waf.

- Clean up the makefile (sort variables and fix indentation)

- Drop the NO_PYTHON variable. It complicates the makefile
  unnecessarily. It is still possible to disable Python support by
  configuring the PYTHON3 option.

- Use WITH_DEBUG instead of option DEBUG.

- Enable PYTHON3 by default.

  The PYTHON3 option is required by net/samba419 to build without the
  bundled dependencies. The primary purpose of databases/ldb28 is to
  make it possible, so enable Python support by default.

PR:		280510
Sponsored by:	Klara, Inc.