flathub / org.gramps_project.Gramps

https://flathub.org/apps/details/org.gramps_project.Gramps
1 stars 1 forks source link

don't use filesystem=home #17

Open alexmo1997 opened 11 months ago

alexmo1997 commented 11 months ago

Using filesystem=home is not really a good practice as it allows access to the whole user home directory which is not needed here.

OzarkShepherd commented 11 months ago

I agree that filesystem=home is not a good practice. and this issue was posted in Feb 2021 at the gramps project github. https://github.com/gramps-project/flatpak/issues/13

Unfortunately, when in 2021 I pushed a Gramps flatpak update to remove home directory access in favor of specific xdg directories, gramps flatpak media access broke for databases that had been restored before that update. That is why I had to revert to the home directory access despite it not being good practice. The reason that media access broke is that when the Gramps app (coded in python) restores a gpkg backup with media included, it creates a new directory in home and labels that directory as the name of the backup it got restored from. I do not want to break current user installations, and I do not know how to compensate for media directories with unknown names in the flatpak manifest. So I submitted a bug report upstream at the gramps project https://gramps-project.org/bugs/view.php?id=12217

Once a python developer fixes this issue in Gramps itself, then I can remove home directory access again in the Gramps flatpak. I even left the commented out xdg directories in the flatpak script for the day that a volunteer upstream fixes this in Gramps. You can see the xdg directories in the commented out lines 10-14 at the manifest here (currently a41153a as of 29 July 2023) https://github.com/flathub/org.gramps_project.Gramps/blob/master/org.gramps_project.Gramps.yml

So the current workaround for users who don't want full home directory access is to use flatseal to change access. Perhaps the upcoming Gramps 5.2 release will fix the media directory issue, I don't know. If you can figure out a script for the manifest that won't break current data for users but still remove access to the entire home directory, then you are welcome to submit a PR at https://github.com/gramps-project/flatpak

Please keep in mind that every flatpak PR must be given about a week for developer review at the gramps project github (linked above) before getting pushed to flathub here, and that we need to retain media access for current Gramps installations.

Nick-Hall commented 11 months ago

Does the Gramps PR #1368 fix this?

OzarkShepherd commented 11 months ago

I am compiling a flatpak now from a test branch to see if PR 1368 fixed the issue. However, I am not optimistic for data from a restored gpkg because they still restore media to a base directory in home as can be seen in the screenshot from a VM I use for testing. Gramps base dir

Nick-Hall commented 11 months ago

When importing a gpkg file, if a media path is not specified in the backup, we use the "Base path for relative media paths".

If the "Base path for relative media paths" is left empty we default to the home directory. Perhaps the xdg pictures directory would be a better default?

Nick-Hall commented 11 months ago

I have opened pull request #1478.

OzarkShepherd commented 11 months ago

Thank you @Nick-Hall for the PR to fix this in Gramps.

  1. So this PR might get merged into both the upcoming 5.1.7 and 5.2.0 releases of Gramps?
  2. If so, may there be an announcement for Gramps shortly before the 5.1.7 and 5.2 releases so that flatpak users will know to either make a gpkg with media before the update, or to move their Gramps media file directories to somewhere in their Pictures or Documents directories?
Nick-Hall commented 11 months ago

The PR has already been merged and is included in the 5.2.0-beta1 release.

I can add instructions for Flatpak users to the release announcement.

OzarkShepherd commented 4 months ago

Sorry, both times we tried getting rid of home directory access, there were issues with data loss. So we needed to go back to home access again.