From Newsgroup: muc.lists.freebsd.ports

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: delphij@FreeBSD.org

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.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Fri, 3 Jul 2026 08:29:33 +0200
Andrea Venturoli <ml@netfence.it> 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: delphij@FreeBSD.org

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 <junchoon@dec.sakura.ne.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

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 <ml@netfence.it> 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: delphij@FreeBSD.org

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 <junchoon@dec.sakura.ne.jp>

--
() ascii ribbon campaign - for an encoding-agnostic world
/\ - against html email - against proprietary attachments


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

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 <fuz@fuz.su> 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 <ml@netfence.it> 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: delphij@FreeBSD.org

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 <junchoon@dec.sakura.ne.jp>

--
() ascii ribbon campaign - for an encoding-agnostic world
/\ - against html email - against proprietary attachments

--
Tomoaki AOKI <junchoon@dec.sakura.ne.jp>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

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 <ml@netfence.it> 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: delphij@FreeBSD.org

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 <junchoon@dec.sakura.ne.jp>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.22a-Linux NewsLink 1.2