Settings in wrong path
Submitted by an unknown user
Link to original bug (#718660)
Description
---- Reported by shotwell-maint@gnome.bugs 2012-04-12 16:53:00 -0700 ----
Original Redmine bug id: 5050
Original URL: http://redmine.yorba.org/issues/5050
Searchable id: yorba-bug-5050
Original author: Robert Ancell
Original description:
The settings are in /apps/shotwell when they should be in /org/yorba/shotwell:
http://mail.gnome.org/archives/desktop-devel-list/2011-February/msg00064.html
This is a bit of a pain as I suspect you really need to migrate them, from IRC talking to Ryan Lortie (desrt):
<robert_ancell>
desrt, btw, have you seen the dconfalypse of everyone sticking
stuff in /apps recently? I've been trying to file bugs to stop everyone
copying the people doing it wrong
<desrt>
ugh
like who?
- desrt ponders doing 'unfriendly' things to people who use /apps/
<desrt>
robert_ancell: from a practical standpoint we're talking about gsettings here, right?
<robert_ancell>
desrt, accerciser, beatbox, brasero, cheese, epiphany, gnome-
nettool, gnumeric, indicator-session, notify-osd, onboasrd, seahorse,
shotwell, telepathy-logger
<desrt>
christ...
<robert_ancell>
desrt, yes
- desrt is thinking of a warning in glib-compile-schemas
<desrt>
"use of /apps /system and /desktop is deprecated"
<robert_ancell>
desrt, and new projects like beatbox / geary are just copying
what older projects are doing. So I've patched those ones and they don't need
to worry about migration but things like cheese are a problem
<robert_ancell>
and basically it seems all of unity has done it wrong
<robert_ancell>
also in /desktop is some gnome crypto stuff, vino, gstreamer
<desrt>
migration is quite easy
<robert_ancell>
and /system contains org.gnome.system.dns_sd
<desrt>
dconf dump /app/whatever/ | dconf load /org/proper/path/ && dconf
reset -f /app/whatever/
<robert_ancell>
desrt, yeah, do you think we should encourage the migration to
be done in the dconf layer?
<desrt>
i think i don't want a migration API
<desrt>
i want people to shell out to that ^^
<robert_ancell>
desrt, and if they weren't using dconf as a backend?
<desrt>
robert_ancell: that's hypothetical enough that i don't really care
<robert_ancell>
desrt, ok, so I've files some bugs, please help squash them
too
<robert_ancell>
I'll do a PSA announcement
<desrt>
robert_ancell: i'm going to add the warning to the schema compiler
<desrt>
that'll make one hell of a lot of noise
<desrt>
i bet those ubuntu punks will vendorpatch it out of existence
<robert_ancell>
desrt, also the gconf migration tool does the wrong thing last
time I checked
<desrt>
oh?
<robert_ancell>
desrt, It copies the gconf patch names which is probably the
main cause of the problem
- desrt recently caught the migration tool doing the wrong thing and fixed it
<robert_ancell>
path names
<desrt>
robert_ancell: oh... the schema migration tool
<desrt>
interesting
<rober_ancell>
desrt, could you recommend the migration on
https://bugzilla.gnome.org/show_bug.cgi?id=673965
<ubot2>
Gnome 673965 in general "Settings in wrong path"
[Normal,Unconfirmed]
<robert_ancell>
desrt, is this the most official statement on what gsettings
paths should be http://mail.gnome.org/archives/desktop-devel-
list/2011-February/msg00064.html?
<robert_ancell>
desrt, then you can set overrides right?
<desrt>
robert_ancell: yes. that email is correct.
Related issues:
- related to shotwell - Bite-sized #6042: [interim] --libexec option in configure script (Fixed)
- related to shotwell - 4410: Settings not preserved in GConf to gsettings conversion (Invalid)
- duplicated by shotwell - 5601: fix deprecated GSettings paths (Duplicate)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:38:00 -0700 ----
History
Comment 1
Updated by Adam Dingle over 1 year ago
- Priority changed from Normal to High
- Target version set to 0.13
OK - I can see there's a big plan to try to get everyone to migrate away from /apps. We should be able to do this for the next release (Shotwell 0.13, shipping this fall).
Comment 2
Updated by Adam Dingle about 1 year ago
- Status changed from Open to Review
- Assignee set to Clinton Rogers
- % Done changed from 0 to 60
Also reported on Launchpad at
https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1039722
Comment 3
Updated by Lucas Beeler about 1 year ago
- Status changed from Review to Open
I'm still waiting for an updated diff that fully fixes this issue. Reverting status to "open."
Comment 4
Updated by Adam Dingle about 1 year ago
- Priority changed from High to Urgent
We should attack this soon, since
(a) this problem generate a bunch of warnings not only when I run Shotwell, but also when other applications are installed, and
(b) settings migration sounds tricky (to me, anyway) so I'd rather not fix this too late in the development cycle.
Upping to Urgent.
Comment 5
Updated by Clinton Rogers about 1 year ago
- File 5050.patch added
- Status changed from Open to Review
- % Done changed from 60 to 70
Comment 6
Updated by Clinton Rogers about 1 year ago
- Status changed from Review to Open
- % Done changed from 70 to 60
Reason: the tumblr plugin needs the same treatment.
Comment 7
Updated by Clinton Rogers about 1 year ago
- File 5050_tumblr-reexport.patch added
- Status changed from Open to Review
- % Done changed from 60 to 70
- Resolution set to fixed
Comment 8
Updated by Clinton Rogers about 1 year ago
-
File deleted (
<strike>
_5050.patch_</strike>
)
Comment 9
Updated by Clinton Rogers about 1 year ago
- Category set to 4
- Status changed from Review to 5
- % Done changed from 70 to 100
Comment 10
Updated by Adam Dingle about 1 year ago
I just tried this and it looks like Shotwell has moved my settings to /org/yorba/shotwell. A few questions:
-
It looks like the settings are also still present in /apps/shotwell. Should we be deleting those?
-
Shotwell only moved the settings after I installed and run, not when I simply ran from the build directory. Does this mean that if someone pulls the latest trunk, builds and runs from that directory without installing, then Shotwell will read from /org/yorba/shotwell even though the settings have not migrated there? In other words, will their Shotwell preferences suddenly seem to be reset to the defaults?
Comment 11
Updated by Clinton Rogers about 1 year ago
Hi Adam,
- It didn't look like there was a safe or easy way to delete an old path after recompiling our schema; I deliberately didn't attempt this so as to not accidentally delete meaningful user settings, but I'd be happy to have a second look at it.
- This seems like a bug; the first time one attempts to launch the app with a version 15 or lower DB, the migrator script should be run. When I tested this last week, it seemed to work even without installing. I'll re-examine shortly.
Comment 12
Updated by Adam Dingle about 1 year ago
- Status changed from 5 to Open
-
Assignee deleted (
<strike>
_Clinton Rogers_</strike>
) - Priority changed from Urgent to High
-
Resolution deleted (
<strike>
_fixed_</strike>
)
Reopening for possible investigation of the points Clinton mentioned.
Comment 13
Updated by Adam Dingle about 1 year ago
- Assignee set to Clinton Rogers
Comment 14
Updated by Clinton Rogers about 1 year ago
Item #1 (moved) is confirmed, unfortunately; to the best of my knowledge, there isn't a way to remove old gsettings keys. The closest we can come is resetting them, and this doesn't have the desired effect.
Comment 15
Updated by Adam Dingle about 1 year ago
What about all the other apps who have recently migrated their gsettings (listed in the chat session above)? After upgrading those apps, are the settings present in both the old and new locations?
Comment 16
Updated by Adam Dingle about 1 year ago
- Target version changed from 0.13 to 0.13.1
Comment 17
Updated by Clinton Rogers about 1 year ago
For those playing along at home, after considerable searching, it doesn't appear there is any way to delete stale keys; I've already run into a few complaints on forums about keys not going away when the schema has changed, so we're not the only project bitten by this, and at least one [message to an official gnome mailing list](http://mail.gnome.org/archives/gnome- love/2012-May/msg00028.html) went completely unanswered.
I sent the following support request to the gtk-app-devel-list:
Hi,
My name is Clint, and I'm one of the developers working on Shotwell.
As part of preparing a fix that migrated our dconf keys away from
/apps/ and into an officially-blessed location under /org/yorba/, we
recently discovered that there didn't appear to be any way to delete
the data in the old path after we'd copied it over to the new one.
How do we fix this? Is it even possible, and/or should we be trying?
A search reveals several others having asked similar questions, but no
definitive answers...
Cheers,
Clint
For the moment, though, cleaning up the old keys may be stonewalled...
Comment 18
Updated by Adam Dingle about 1 year ago
-
Assignee deleted (
<strike>
_Clinton Rogers_</strike>
) -
Target version deleted (
<strike>
_0.13.1_</strike>
)
OK. Let's defer this unless we get better news here.
Comment 19
Updated by Thomas Moschny about 1 year ago
I just did this (after the migrate script has been run):
dconf reset -f /apps/shotwell/
After that, /apps/shotwell/
is gone.
Comment 20
Updated by Lucas Beeler about 1 year ago
- Assignee set to Clinton Rogers
- Target version set to 0.13.1
Re-assigning to Clinton and re-milestoning for 0.13.1 based on Thomas Moschny's comment above that deleting the keyset may be possible after schemas have been recompiled and the dconf reset utility is run. Clinton, please investigate whether this approach gets us to where we need to be.
Comment 21
Updated by Clinton Rogers about 1 year ago
- Status changed from Open to Review
- % Done changed from 100 to 90
Comment 22
Updated by Lucas Beeler about 1 year ago
- Status changed from Review to Open
Comment 23
Updated by Clinton Rogers about 1 year ago
- % Done changed from 90 to 100
- Resolution set to fixed
Comment 24
Updated by Clinton Rogers about 1 year ago
- Status changed from Open to 5
Comment 25
Updated by Fryderyk Dziarmagowski about 1 year ago
Hardcoding distribution specific libexec here is wrong. This is something what should be configurable at build time.
Comment 26
Updated by Jim Nelson about 1 year ago
What alternative would you suggest?
Comment 27
Updated by Thomas Moschny about 1 year ago
You could include(GNUInstallDirs)
which defines a set of standard
installation dirs, including CMAKE_INSTALL_LIBEXECDIR
. They can be
overridden in the cmake
call, iirc.
Comment 28
Updated by Jim Nelson about 1 year ago
- Status changed from 5 to Open
-
Assignee deleted (
<strike>
_Clinton Rogers_</strike>
) - Target version changed from 0.13.1 to 0.14.0
-
Resolution deleted (
<strike>
_fixed_</strike>
)
Shotwell doesn't use CMake, it uses a custom Makefile. Is there some way to get this directory with native calls?
Moving this to 0.14 for reconsideration.
Comment 29
Updated by Thomas Moschny about 1 year ago
Ah, right, got confused.
Well, Fryderyk's concern was about hard-coding the location. So, what about
keeping the default to $(prefix)/libexec
, but adding a configure
option
for it?
Comment 30
Updated by Jim Nelson about 1 year ago
That seems reasonable. If there's an automated way to do this, I would be interested to know that as well.
Comment 31
Updated by Fryderyk Dziarmagowski about 1 year ago
According to FHS:
/usr/lib includes object files, libraries, and internal binaries that are not intended to be executed
directly by users or shell scripts.
...
Applications may use a single subdirectory under /usr/lib. If an application uses a subdirectory,
all architecture-dependent data exclusively used by the application must be placed within that subdirectory.
So defaulting to /usr/libexec ist still not standard conform, it should be /usr/lib/shotwell
I can agree with Thomas, passing --libexecdir to configure would be the best option (since this is a common standard), but with above default and not fedora-like libexec one.
Comment 32
Updated by Fryderyk Dziarmagowski about 1 year ago
One minor thing: /usr/lib can be /usr/lib64 on some distributions.
Comment 33
Updated by Thomas Moschny about 1 year ago
From my pov, /usr/{lib,lib64}/shotwell
would also be ok.
That said, the (hopefully) upcoming version 3 of the FHS mentions /usr/libexec here http://www.linuxbase.org/betaspecs/fhs/fhs.html#usrlibexec as it really has become a common standard.
Comment 34
Updated by Jim Nelson 11 months ago
- Category set to library-mode
Comment 35
Updated by Jim Nelson 11 months ago
- Status changed from Open to 5
- Resolution set to fixed
Adding a --libexec option is #6042, so closing this ticket as completed. I'll add a comment to that ticket to make sure that the GSettings migrator respects the setting.
Comment 36
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Fixed
--- Bug imported by chaz@yorba.org 2013-11-25 21:57 UTC ---
This bug was previously known as bug 5050 at http://redmine.yorba.org/show_bug.cgi?id=5050 Imported an attachment (id=262472)
Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Version: 0.14.0
Resolution: RESOLVED FIXED