Specifically pertaining to commonized GPG.
on the one hand:
PortableDrive:\
+\PortableApps\
+\CommonFiles\
+\gpg\
+\App\ {GPG binaries}
+\Data\ {GPG Home dir, keyrings and conf}Seems more concise and organized. But the data dir is missed by PortableAppsBackup.
On the other:
PortableDrive:\
+\PortableApps\
+\CommonFiles\
+\gpg\
+\App\ {GPG binaries}
+\gpg\
+\Data\ {GPG Home dir, keyrings and conf}Feels less organized, but PortableAppsBackup should now get the keyrings without any modification.
Any thoughts?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
is better. Unless John wants/plans to change the backup program...
"What about Love?" - "Overrated. Biochemically no different than eating large quantities of chocolate." - Al Pacino in The Devils Advocate
The disadvantage of the second one is that it is not intuitive to the user that the stuff in the PortableApps\GPG folder is needed by other programs. It makes it more difficult to identify dependency items when you're uninstalling things, but, more inmportantly, it would lead to a rash of users who quite reasonably decide that since they never installed XYZ-application, and since it doesn't even show on their menu anyways, they don't need it, don't want it, and have just deleted it to save precious space. Now why has ThunderBird / GIMP / pidgin / whatever suddenly just stopped working...
Personally, I think that if the PortableApps system is going to move towards more use of shared libraries such as these (which I really hope that it is), then it would be much better to do it right, and to fix the backup system to cope with it, rather than to kludge it. Especially since it would probably take more programming effort to change the apps that already use commonfiles than it would to change the backup system.
Any reason for using ./gpg instead of ./gnupg? (That's what the distro uses, though the other is common too.)
I expect John will have an idea about it, and once he lets us know, things will settle down. Setting the GPG_HOME environment variable can take care of wherever the keys might be.
The notion of backup is important; you want to backup the personal files (key rings) and settings, but not necessarily all the application files, so it would be good to keep them separated. I've wondered why John didn't borrow the idea of a HOME directory, and keep settings and such there. Not that you need to keep one person's things from another user, since a USB drive is basically for one user, but still, it would simplify backups, and it is a structure that could be used in Linux too, sharing settings for GnuPG or possibly SSH or VIM, etc. between a Windows machine and a Linux machine.
Anyway, John will come up with something.
MC
Keeping the settings close to the app makes for easier maintenance - both uninstallation and also copying / moving apps from one drive to another or sharing the settings with other users.
Once you consider just how many of the apps use settings.ini, or something similarly generic, you end up needing a folder for each app in $HOME anyway.
So, while it may be easier for backups, it is tougher for other operations, and, since backups are usually automated by a script, rather than done manually like uninstalls or copies, this way optimises for the user interactions.
I think I have come up with a good compromise.
PortableDrive:\ +\PortableApps\ +\CommonFiles\ +\Data\ +\GnuPG\ {GnuPG Home dir, keyrings and conf} +\GnuPG\ +\App\ {GnuPG binaries}In this manner all GnuPG files are in the CommonFiles directory where they belong. The CommonFiles\Data folder is picked up by the current backup tool without modification. And other common Files can put their settings in the CommonFiles\Data to take advantage of the current backup method as well.
It is a permutation of the PAF structure, but then again PAF is for single app per structure where as the commonFiles structure is for multiple apps in one.
I have more GnuPG specific things to go over, but that will warrant a new thread.
Thank you for the input everybody
Key ID: 0xDAE3095F
Fingerprint: 5D98 65D2 1844 21A5 76C1 F0F6 4BE6 D689 DAE3 095F