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]>
>>