Building arm64 using MacPorts


I have been using the 5.1.4-2 Intel binary provided in the dmg on an apple silicon m1 arm64 machine. It has been working flawlessly!

Out of curiosity has anybody built gramps on arm64? I was hoping somebody here might know how to configure MacPort to build gramps using the sqlite3 backend.

db53 won’t build and its already listed as a broken port on MacPort.




The MacPorts version is configured to allow use of sqlite3. What I suppose we would need is a way to disable Berkley DB. Is this even an option for Gramps?

Re Berkely, I see that your ticket was closed as a duplicate and that the referenced ticket explains that licensing of Berkley is a problem in the Oracle era. The Wikipedia article says that Debian has phased out Berkely in favour of LMDB (Lightning Memory-Mapped Database). I know almost nothing about these different database systems or the Python modules to access them.

Is Gramps planning to continue to use Berkley DB or migrate away from it?


Gramps enabled SQLite as an alternative database backend in version 5.0 and migrated to that as the default (away from BSDDB) with the 5.1 version.

However, users upgrading to Gramps 5.0 or 5.1 must proactively choose to convert their version 4.x tree databases to SQLite. This does not happen automatically nor is there a ‘nag’ from Gramps to do so.

So users who do not pay attention to messages that they should convert may remain oblivious to the benefits of conversion.

There was a brief discussion thread about removing BSDDB from the core. There seemed to be no consensus reached in either direction.

The next major upgrade to Gramps will be making SQLite the default, and will force upgrade all trees to that db type. However this still requires that bsddb be present in the machine (to allow reading for the upgrade). If having bsddb becomes a problem in the future, we could modify Gramps to operate without it, although that would prevent Gramps from doing upgrades.

1 Like

As a counterpoint to that approach… Gramps has failed to provide seamless backward file format compatibility in the past and that choice has hurt the reputation of the project.

It is ok (even necessary) to change formats. But some ability to fail gracefully, while unambiguously identifying the old format and offering a upgrade/conversion tool (which probably ought to be external) is vital. Without that, Gramps loses credibility as a stable alternative to being orphaned by commercial software or evaporating cloud services.

I am guessing 5.1 will stay downloadable on the internet somewhere, so if future version stop being able to convert flawlessly, you could get people to download that, then convert, then download the newest version.
Not saying that is good or not but maybe an option IF it was to break.

Regardless of which backend database is used, is it not the case that the backups use the same compressed XML format? If so, then users who are upgrading can simply install the new version and load their tree from their latest backup?

Superficially, that might seem to be a reasonable option. Operationally, it appears to be unworkable.

I recently need to downgrade to an old (3.4.9) version of Gramps to help recover an old database from the harddrive of a new user’s deceased relative. And to test for a performance degradation bug.

It seemed like a good opportunity to get the same big data sample in 4.2.8 and 5.1.3 versions. I figured that since PortableApps versions of all those version existed, getting the same data in all 3 should be an easy task. And the task resulted in an seemingly endless series of complaints from Gramps that data was in incompatible formats (without identifying the version) that could not be read.

What should have been a single complaint (that told me which old version of Gramps had to be installed to load the file & export the file to XML) required examining the hexadecimal of the database. Then, when I finally recovered the data with an obscenely dated 2.x version of GRAMPS and saved it as a backup, the newest version of Gramps said the backup was not compatible… it had to be incrementally upgraded through 2 other versions of Gramps before it could be read in the current version!

I shoulda saved it in GEDCOM! Gramps would have dealt with that better than its own internal format.

We REALLY should avoid adding onto that labyrinth.

Re: [Gramps-devel] Proposal to remove the BSDDB backend

From: Nick Hall <nick-h@gr…> - 2020-01-24 19:39:38
On 24/01/2020 17:35, Ross Gammon wrote: > Here are the current supported releases in Debian:
Old Stable (Stretch) 4.2.5
Stable (Buster): 5.0.1

Trusty 14.04 (LTS): 4.0.3
Xenial 16.04 (LTS) 4.2.2
Bionic 18.04 (LTS) 4.2.8

Thanks. That is useful information. I have just written a script that copies raw data from a BSDDB database into an empty SQLite database. It works with v4.2 and newer.
Obviously bsddb3 and its python bindings are still required for this, but could be made optional.
For older versions, the Gramps XML will always be supported.

Unfortunately, the thread does not continue or say where that script was shared… if it was shared.

It might have been useful for another user who was attempting to write a Python script would do a batch operation on all the Trees normally findable by the Manage Family Trees dialog. (She wanted tool to do a batch of backups prior to installing upgrades. She intended to offload guaranteed current XML… with Media… of ALL Trees from a single trigger by the user.) She was unsuccessful in getting Python to list the Tree databases.

By the way, working with backups was complicated by the fact that these archives are double or triple ZIP compressed. So to see the header of an XML Gramps file to determine which version of Gramps should be used, you have to extract a file from an extracted file that had to be extracted.

No project in the world provides backward compatibility.

I used the wrong phrasing. The ability to identify and modernize (internally or externally) any old version of the native file formats to the current version.

Although uncommon, the ability to downgrade (WITH DATA LOSS FOR INCOMPATIBLE FEATURES) to superseded file formats exists in many larger projects… including GIMP, MS Office suite, AutoCAD, etc.

I doubt that many with as small number of developers as this project are doing so. So it would not be reasonable to have such a complex function inside the core of Gramps.

But let’s take the worst case that our next application could not be made to work with old file formats. (For instance, if Gramps is forced to update to a version of Python that is incompatible with any BSDDB engine.)

Would it be possible to keep a plumber’s nightmare collection of headless CLI import/export modules (with the appropriately lower Python libraries) where you could pipe in the initial format, the modules update to their highest format, and then pipes it off to the next, more modern module. And that module does the same… until the version reaches the target format.

Such a plumber’s nightmare would be a separate project collection. It would be slow, ugly & inefficient. But it would keep potable data from becoming sewage. And do so with a minimum of user interaction.

What Gramps would have to do is: politely refuse when fed an old format, identify the format version accurately and suggest that the user download & use the right tool for that data version.

(The unrealistically ideal solution would be that Gramps would check if the tool was installed, if so, trigger a batch file which points at the problem source file and requesting the target version to be delivered & specifying where it would be delivered.

And once data flowed one direction in the pipeline, it could be made to flow the opposite direction for downgrades… with inevitable data loss expected.)

1 Like

I don’t know about Windows or Unix, but on Mac it’s easy to see which version of Gramps created the backup; it shows up in the file type, for example, “ Document” (that is what appears as the backup file’s “Kind” in Mac’s “Finder” app).

Oops, I have to withdraw that remark (but leave this reply so others don’t make the same mistake I just did); all of my backups, even those from previous releases, show up with current release number in the file’s “Kind”.

Maybe there should be a feature request to allow users to control how backup file names are generated? For example, to optionally include the release number in the file name.

If this is the way that the Mac file & creator types worked in the past, then those are only inviolate when the application owning that creator type in the Registry does not change. It is also inherited without changes when there is no application associated with that Creator Type in the Registry.

Otherwise, if the application with the Creator type is updates and ‘owns’ the file types, then that data will change.

When I was director of development for a high-end 3-D product in the 90s, we had a (fairly expensive) Developer annual license with Apple and had to re-register new Creator types if the file formats were not backward compatible.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.