Hi. +1.
Considering future maintainance burden and pains in transition, *Revert databases/lmdb back to previous version (PORTEPOCH bump) *Add something like databases/lmdb1 for 1.0 to ease tests / developments by maintainers of consumer ports *Once all maintainers for consumer ports are ready to update, update databases/lmdb again with all consumer ports in single commit (to avoid breakage by incompatibilities) *Remove now-unneeded databases/lmdb1 to lower maintainance burden may be realistic. Isn't it? The transition period could be quite long, if upstream keeps on supporting previous version for a long time. Regards. On Fri, 3 Jul 2026 16:45:28 +0200 Robert Clausecker <[email protected]> wrote: > With this in mind, wouldn't it have been better to make a new port for > lmdb 1.0 such that existing software continues to work unchanged? > The soname is different, so the two can exist side by side. > > Yours, > Robert Clausecker > > Am Fri, Jul 03, 2026 at 09:12:54PM +0900 schrieb Tomoaki AOKI: > > On Fri, 3 Jul 2026 08:29:33 +0200 > > Andrea Venturoli <[email protected]> wrote: > > > > > On 7/2/26 21:05, FreeBSD ports/UPDATING: Alexander Kojevnikov wrote: > > > > > > > > AFFECTS: users of databases/lmdb <http://updating.kojevnikov.com/atom/ > > > > ports> > > > > > > > > 20260702: > > > > AFFECTS: users of databases/lmdb > > > > AUTHOR: [email protected] > > > > > > > > LMDB 1.0 introduced an incompatible on-disk file format change. > > > > Versions 0.9.x and 1.0.x databases are mutually incompatible. > > > > > > > > Before upgrading, export all existing databases using the old v0.9 > > > > mdb_dump utility, then import them with the new v1.0 mdb_load after > > > > upgrading. There is no support for opening v0.9 database files > > > > directly with LMDB 1.0. > > > > > > > > Example migration procedure: > > > > # mdb_dump -a /path/to/db > /tmp/mydb.dump > > > > # pkg upgrade databases/lmdb > > > > # mdb_load -f /tmp/mydb.dump /path/to/newdb > > > > > > Hello. > > > How does this affect Samba installations? > > > Do we need to do this procedure? > > > Does Samba do it automatically? > > > Is it not neede in this specific case? > > > > > > bye & Thanks > > > av. > > > > Hi. > > > > Not sure how samba uses lmdb (I'm not configuring samba > > on my computer myself, but using smbfs to connect to NAS), > > possible use-cases would be... > > > > *To store configuration > > > > *To store extended attributes / ACLs on local filesystems > > that doesn't support them natively > > > > *To store ID / password that are NOT assured to be exactly > > the same as underlying host OS (samba specific IDs / passwords) > > > > > > Anyway, samba would be needed to be rebuilt if you upgrade > > databases/lmdb, as the library major version is bumped > > and shared object filename is changed. > > > > lib/liblmdb.so.0 is switched to lib/liblmdb.so.1.0 > > (lib/liblmdb.so.1 would be a symlink to lib/liblmdb.so.1.0). > > > > > > If you're not upgraded yet and not enough sure it's OK, > > you can stick with previous version with > > `pkg lock databases/lmdb`. > > > > In this case, to be safest, you'll need to lock anything > > (at least directly) depending upon databases/lmdb, too. > > > > You can determine direct dependencies with > > `pkg query %ro databases/lmdb`. > > > > Regards. > > > > -- > > Tomoaki AOKI <[email protected]> > > > > -- > () ascii ribbon campaign - for an encoding-agnostic world > /\ - against html email - against proprietary attachments > -- Tomoaki AOKI <[email protected]>
