On Sat, 4 Jul 2026 12:44:09 +0200 Daniel Engberg <[email protected]> wrote:
> On 2026-07-04 11:45, Gert Doering wrote: > > Hi, > > > > On Sat, Jul 04, 2026 at 11:40:32AM +0200, Michael Grimm wrote: > >>> Can we get databases/lmdb reverted to 0.93.5, and 1.0.0 added as a > >>> separate origin? > >> +1 > > +1 - and then depending packages can decide how they can migrate, without > > breaking user setups when running a naive "pkg upgrade"... (POLA). > > > > gert > > There are two different issues here, Migration and compatibility People > really need to get rid of the "I don't want to change" mindset > especially tracking head/master. POLA is not about that, we can't police > upstream projects and doing forks / extensive patching isn't reasonable > and neither what any other distro / package repo does. If upstream makes > changes users need to follow. We can apply POLA to projects we own but > expecting that to carry out to third party is obviously out of our > hands. What we can do is however to inform about breaking changes and > try to make the migration as painless as possible. I'm not suggesting > that we knowingly should break things just to the sake of it but on the > other hand these kind of issues have occurred before and will occur from > time to time. Compatibility As Arch people have noted there also seems > to be runtime and (?) build issues, that however needs to be addressed. > Given that time frame and affected ports it's likely a better idea to > revert the commit and create a meta PR for upgrading 1.x instead of > having multiple versions in parallel. > > What can we learn from this? Changelogs are important and to be fair one > could argue that this information wasn't easily obtainable / well > communicated. > > https://lists.openldap.org/hyperkitty/list/[email protected]/thread/P347LVJF4UAA3XL7D7ITJGJI54UAARXC/ > > https://www.lmdb.tech --> "Technical Information" (below download > button) --> More documentation --> "Upgrading From Release > 0.9"http://www.lmdb.tech/doc/upgrading.html > > No CI pre commit doesn't help, "exp-run"-ish requirement/checks and > expecting a committer to have access to two different releases and at > least three arch's (amd64, aarch64 and if possible i386 (I know its > being phased out)) is a bit of a tall order, we're all humans and we can > miss things. Best regards, Daniel Hi. Don't forget, databases/lmdb is a "database" port. For library incompatibilities, basically it can be worked around by ports side, not bothering users (excepts waiting for new pkg to be available). With this aspect, nothing different with non-database ports. For migrations, the "better" way would be to allow installing and running new one aside of previous one, run both at the same time, and vacuum from previous and pass the data to new one with special "migraiton" mode. (Off topic here, but it would be nice if different versions of databases/postgres* ports don't conflict each other.) Of course, the best is to versioning database format and new software versions always support reading older format, and provide converters for painless (except disk capacity) migrations. So I've noted "better" above. Regards. -- Tomoaki AOKI <[email protected]>
