Closed mMerlin closed 7 months ago
gasinvein
commented
5 years ago This is expected behavior. Flatpak mounts the app bundle read-only, and Fritzing parts are packaged within the bundle. Maybe self-updates shoud be disabled at compile-time, if possible.
mMerlin
commented
5 years ago The parts library is bundled, but it is supposed to be tied to the git repository. Updates to the library (data) should not be limited to a new version of the application. Probably do not want a full library update either, when a simple git pull (equivalent) is all that is really needed.
gasinvein
commented
5 years ago Fritzing parts are installed in a system-wide prefix (either /usr in distro packages or /app in flatpak) and are not intended to be writable by user. And, as far as I know, parts version is somehow tied to Fritzing's version.
Maybe it can use 3rd-party parts from user's `/home'?
mMerlin
commented
5 years ago When installed with --user the user should have write access to the app and its data. No, the parts version is not tied to the app version. The parts library is effectively a data base, and can be updated separately. I have been doing that previously with a custom local build of Fritzing 0.9.3b (back on fc24). When setup 'right', a git pull will get library updates without touching the app itself. Without flatpak, parts added by the user get stored in the same folder structure.
I just continued my testing. Likely for the same reason, it is not possible to load new parts. Attempting to open an fzpz file gives error Unable to open shareable part '/run/user/1000/doc/«hexfolder»/«filename».fzpx': zip.open(): %d. The console shows:
QString::arg: Argument missing: "zip.open(): %d" , -1000
"zip.open(): %d"
TingPing
commented
5 years ago Flatpak restricts permissions beyond what your user can do. You cannot write to /app in the sandbox, ever.
The plan is for the portals to expose a way to request updating the Flatpak on the host. Until then applications can currently detect when they got updated and restart themselves but not update themselves.
It is very questionable to want to bypass all tooling and update yourself but if you need to do that today you just write to your directory $XDG_DATA_HOME or something.
mMerlin
commented
5 years ago Looks like Fritzing is going to need some sort of structure change to fully work with flatpak then. As is, it is not possible to import custom parts. Because of where the information gets stored.
gasinvein
commented
5 years ago @mMerlin The default parts library is installed along with the app itself, to a location which is not intended to be writable. In case of distro packages, like debian's or fedora's, it's installed in /usr/share/fritzing/parts. Normal user shouldn't be able to update it.
TingPing
commented
5 years ago Flatpak extensions can be mounted into /app though (but will still likely require minor patches for path changes): https://blog.tingping.se/2018/03/18/flatpaking-plugins.html
(Admittedly I don't know what parts are and if that makes sense)
mMerlin
commented
5 years ago Parts library: electronic parts: transistors, resistors, capacitors, as base, but also including full boards like arduino, raspberry pi. In application context, new parts can be defined and added at any time. Parts library is really a database, but it is stored as individual files (svg, xml, zip) in a directory structure. The library also includes 'bins', which parts can be added to, to collect commonly related parts for easy access during design work.
Does flatpak support the idea of a database that the application updates during execution? More than just a config file. Current Fritzing implementation stores the parts in nested sub-folders where the application executable exists. I don't know about implementation details, but conceptually it should be easy to move that some place else. Which would probably let flatpak allow write access to it.
TingPing
commented
5 years ago Does flatpak support the idea of a database that the application updates during execution?
That really sounds like it should go into $XDG_DATA_HOME/fritzing/parts if Fritzing is managing the data.
gasinvein
commented
5 years ago Well, we can make /app/share/fritzing/parts a symlink to a user-writable location, e.g. /var/data/fritzing/parts, and add a wrapper which would set things up before app launch, but I doubt it's a good idea.
Does the self-update work in distro packages? Can Fritzing use multiple locations to load parts from?
mMerlin
commented
5 years ago When I looked (a very little) at the code a year ago, the distro package for Fedora was 0.9.2. That version did not do library updates. What I read (forums) said the updates were working with the newer version.
What I remember says that the current version of the code uses a single location, and that it is not settable by the user. Built into the code. The symlink might not be a good idea, but if it works, Fritzing (flatpak) might become usable. As is, it is only a toy. No library updates, no imported parts, no custom parts. At least not without going under the hood, and bypassing the security that flatpak is intended to enforce.
gasinvein
commented
5 years ago no imported parts, no custom parts
Actually, you can use imported parts, they are saved to ~/Documents/Fritzing/parts/user. Also, I guess it's same for custom parts, didn't use them.
updates were working with the newer version
It's likely related not to the app version, but to how the app is installed. Updates within a standalone binary, stored somewhere in your /home, would work, and for a system package they wouldn't.
mMerlin
commented
5 years ago Actually, you can use imported parts, they are saved to
~/Documents/Fritzing/parts/user. Also, I guess it's same for custom parts, didn't use them.
Correct. I had an error in my test steps. Import works.
updates were working with the newer version
It's likely related not to the app version, but to how the app is installed.
My information is that the 0.9.2 version of the app did not have the capability to do library updates. That was added in 0.9.3. Which was why I could not verify that the standard distro install could do updates. The distro I was using only installed 0.9.2.
gasinvein
commented
5 years ago If parts are installed to a system directory, it's assumed that they are not manageable by the app. Otherwise, Fritzing should look for parts somwhere in $XDG_DATA_HOME and not in it's installation prefix. So I consider this correct behavior.
Probably, we could split the parts library to an extension, so they could be updated separately from Fritzing itself.
gasinvein
commented
4 years ago Fritzing now (0.9.4) supports --parts path argument for specifying path to the parts repository. Once #7 is merged, I'll also add a wrapper so that users could override part repo path to their own.
KjellMorgenstern
commented
7 months ago The Fritzing code that handles these updates isn't very robust. A problematic push to the fritzing-parts repo could damage all Fritzings that check for these updates. It has been a source for many support requests and errors.
Therefore we don't use the fritzing-parts master branch anymore (could still damage some old Fritzing installs). Also, automatic parts update via git is disabled in all recent versions.
The git feature can still be used manually (with the --parts option) for working with custom parts repos.
environment 4.18.16-100.fc27.x86_64 ¦ Fedora 27 Fritzing: 0.9.3 b5c8959
Fritzing installed from flatpak, even with
--user, is unable to update the parts library. The installation does not have write permissions to the parts folder.Fritzing ¦ Help ¦ About
Fritzing ¦ Help ¦ Check for updates
Checking the current file access permissions, it appears that the user does have write permissions. What user is attempting to do the check and update?
Same error seen when using
install --system. That made more sense, since the running user does not automatically have root access.