As the app's main window calls itself "Sound Juicer" that is what the Desktop entry should be labeled in my view. I understand that it may make sense with this app pre-installed as the only CD ripper around in something like Ubuntu. However, we are not Ubuntu. Thanks! If I do not hear from you within a week, I may patch this myself.
Check this out with upstream. There's no reason to change the labeling of such things just for the fun of holding patches.
(In reply to comment #1) > Check this out with upstream. There actually is an open bug for this. It's been open for over a year now but upstream doesn't bother even replying once: https://bugzilla.gnome.org/show_bug.cgi?id=616860 Seen the same myself when asking for a repeat toggle over 4 years ago, no reply ever either: https://bugzilla.gnome.org/show_bug.cgi?id=424506 Btw the bugzilla product is called "sound-juicer" and people call it "Audio CD Extractor" or "Sound Juicer CD Extractor" in their bug reports. What a mess. I'll see if I can find a Gnome person who can help approach this problem during Desktop Summit 2011. > There's no reason to change the labeling of such > things just for the fun of holding patches. The problem of downstream patches is the need for porting from release to release. In contrast, the kind of patch we are talking here does not have that problem and therefore patching that downstream is no big deal. If patching stuff like that is no fun to you, maybe someone should take care of this package other than you.
This is a trivial improvement that satisfies Gnome policy (see https://live.gnome.org/GnomeGoals/CorrectDesktopFiles). Upstream appears to be unresponsive, and I see no reason why we shouldn't simply fix it. I've patched sound-juicer in the overlay.
Will try to fix this in the tree in the near future then
Patch as been approved upstream. Feel free to apply.
Patch integrated, closing.
@sping, please pay attention to our ebuild style guidelines if you actually want to be a maintainer of any gnome herd ebuild.
Where is it documented?
(In reply to comment #8) > Where is it documented? It's not documented, as far as I know, but if you read some gnome-related ebuilds, you will see that they all follow a common pattern. For example, the functions are in chronological order: pkg_setup before src_prepare. If you place src_prepare before pkg_setup, a reader who is used to gnome ebuilds will, at first glance, assume that this ebuild's pkg_setup is default/empty.
Thoughts: - I can stick to that order, sure. Seems like eva fixed it for me, silently. - Assuming an empty src_prepare because of a soft rule (in contrast to a rule that would deny compilation) doesn't sound reasonable to me - Let's get these rules documented
About using gnome2_src_prepare, I think it makes sense to manually run it since this package uses gnome2.eclass and, then, when no src_prepare was set before applying this patch, gnome2_src_prepare was being executed automatically. If we apply the patch without running gnome2_src_prepare manually, the behavior for this phase is also changing ;-) In summary, you can look to the eclass to see what phases are being exported and, then, try to keep them being used when we need to set a different phase for any additional change.
