Re: AFFECTS: users of databases/lmdb
Daniel Engberg <[email protected]> Sun, 5 Jul 2026 07:47:41 +0200
| Newsgroups | gmane.os.freebsd.devel.ports |
|---|---|
| Message-ID | <[email protected]> |
Except that rarely works out well in the end and you have a non versioned lmdb.pc meaning that you'd need to hack consumers manually to ensure they grab the "correct" version. Which is why a meta PR is likely the best solution for this as I suggested earlier. Best regards, Daniel On 2026-07-03 16:45, Robert Clausecker 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]> >>