Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change in build 88678 rejected #21

Open
flathubbot opened this issue Mar 9, 2024 · 4 comments
Open

Change in build 88678 rejected #21

flathubbot opened this issue Mar 9, 2024 · 4 comments

Comments

@flathubbot
Copy link

A change in build 88678 has been reviewed by the Flathub team, and rejected for the following reason:

These shouldn't be filesystem. If the problem is that they don't persist then use the persist option. Ideally this should be fixed upstream to conform the the xdg directories specification.

Changes

Field Old value New value
filesystems ['xdg-documents', 'xdg-download', 'xdg-pictures'] ['xdg-documents', 'xdg-download', 'xdg-pictures', '/.cache:create', '/.config:create', '/.gramps:create', '/.local/share:create']
@OzarkShepherd
Copy link
Collaborator

The problem is that upstream has changed to using xdg directory specs from its prior use of ~/.gramps in prior versions, but flathub is preventing the Gramps flatpak from using the same xdg specifications when a user wants to switch between a system installation and the flatpak. Using --persist is not good enough if someone wants to switch between a flatpak or system install, because a system installed version of an app won't be looking at where the flatpak version using --persist copied the files to. This is giving users a bad impression of flatpak, in that when they try the flatpak they find that they lose all their work due to flathub's rejection of using xdg-data, xdg-config, and xdg-cache in the same way that a system installed app would. By demanding the use of --persist, you are taking away the choice of users in going back to system installed apps. Please view things from a user's perspective occasionally.

@hfiguiere
Copy link
Contributor

when a user wants to switch between a system installation and the flatpak.

this has NEVER been a supported use case in flatpak.

@TingPing
Copy link
Member

TingPing commented Mar 11, 2024

you are taking away the choice of users in going back to system installed apps.

Maybe this is OK for Gramps if it never has and never will break compat, but in general this is a broken concept. The system package could be 3 years older of a version. The config files could include file paths that no longer exist also.

@OzarkShepherd
Copy link
Collaborator

OzarkShepherd commented Mar 11, 2024

Maybe this is OK for Gramps, but in general this is a broken concept. The system package could be 3 years older of a version. The config files could include file paths that no longer exist also.

I see your point that many packages, especially in debian stable (without backports added) or centos, are older versions that will never get anything more than security updates. However, some apps (like Gramps) do make source installs, deb, and even rpm installs available for users. For the Gramps 5.2 update, the deb install file is still being worked on, but the source install in tar form is currently available at the link below. There have been users excited about trying out the update only to find disappointment at losing data when trying the flatpak. Some of these user databases include many years of the user's work on family connections, so losing data can feel catastrophic for them. I personally have had my research database corrupted multiple times by a competitor app named Family Tree Maker 2016, so that made me seek more reliable alternatives (currently Gramps in my case). That is why I have so much sympathy for those who lose access to their research and don't know how to recover it. So at least for Gramps, being able to go between a flatpak and a system install is important.
https://github.com/gramps-project/gramps/releases

Some Gramps flatpak users did not know that an update was coming, so they were not prepared. Some of those users sought help, but what about those who had no idea where to seek help?

EDIT regarding deprecated config files: Gramps 5.1 and earlier did use ~/.gramps that is now being phased out as 5.2 is switching over to xdg-data, xdg-config, and xdg-cache in an effort to use xdg standards. (That is why part of why the "Ideally this should be fixed upstream to conform the the xdg directories specification." set me off, because they are trying.) In order to prevent user data loss my understanding is that the upstream update to Gramps 5.2 first checks for the existence of ~/.gramps and uses that if it exists. If ~/.gramps does not exist, then Gramps 5.2 uses xdg-data, xdg-config, and xdg-cache. So restoring a backup Gramps database onto a PC with a fresh linux install will use xdg standards, and slowly users will be transitioned away from the deprecated use of ~/.gramps.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants