GNOME Bugzilla – Bug 557443
Move <DefaultMergeDirs/> to the bottom of the menu files
Last modified: 2010-07-16 10:43:52 UTC
In application.menu and settings.menu, <DefaultMergeDirs/> is near the top, before the menu is laid out. Being at the top of the file means that any, for example, <Exclude> directives won't work, because nothing has been <Include>'d yet. So it restricts merge menus to only adding, never removing. Nor can they change the layout, as the last <Layout> wins. From a system-builder POV, this complicates easily customizing the menu. From a concern-about-third-parties-maliciously-screwing-up-the-menu POV, it makes some sense. Is this a feature or a bug? If it's a bug, I'd propose moving the DefaultMergeDirs line to the bottom of the <Menu>. If it's a feature, close this bug with prejudice.
<DefaultMergeDirs/> really exists for third-parties, and not for the system-builder. I wouldn't recommend using it this way. Note that since the order of <Include> and <Exclude> matters, the issue you have with <Exclude> that don't work has an opposite for the case of <DefaultMergeDirs/> being at the end: stuff cannot be excluded from there...
Can you explain why you wouldn't recommend using it that way? I presume your preferred method is customizing the package that installs the default menu and shipping a different one instead? That works, sure, but it's easier to drop a file in a directory and be done with it. Particularly if you can have different packages that can install different menu customizations and leave the base one around and unmolested. My point is just that it would make system-builder's lives easier, and that surely is somewhat valuable. As for your point about no longer being able to <Exclude> from the main applications.menu/settings.menu items that gets introduced by merged menus, I still don't see the utility. The default applications.menu and settings.menu don't <Exclude> anything by default. And it's hard to imagine the use-case... One I can imagine is that it lets the shipped-by-default applications.menu pre-emptively <Exclude>'ing an <Include> in a known-bad/malicious third-party merge menu. Seems much more valuable to not favor that theoretical feature over the ability of merge menus to both <Include> and <Exclude>. Especially since third-party merge menus can be malicious in plenty of other ways. I'm not reopening this bug, but I'd really appreciate a second look.
(In reply to comment #2) > Can you explain why you wouldn't recommend using it that way? I presume your > preferred method is customizing the package that installs the default menu and > shipping a different one instead? Yes, indeed. > That works, sure, but it's easier to drop a > file in a directory and be done with it. Particularly if you can have > different packages that can install different menu customizations and leave the > base one around and unmolested. I'm not sure how it's an issue. You can definitely ship various applications.menu in different packages that conflict with each other. That's merely a packaging issue that's 100% solvable -- as an example, in openSUSE, we have gnome-menus-branding-upstream and gnome-menus-branding-openSUSE. > My point is just that it would make system-builder's lives easier, and that > surely is somewhat valuable. My point is that it's not possible to guarantee that it will work as intended. It should, but there will always be cases where that won't be what you expect. Another example is that the last <Layout> wins -- while this is an argument you give, it's totally possible a third party might ship something with <Layout> too and breaks your stuff. (and my second point is that, as I already said, this is packaging issue)
I never claimed the problem was anything other than a packaging issue or not solvable. I was just trying to make it possible to solve it in another, arguably-easier way. I agree there are issues with last-Layout-wins since a third-party merge menu can't know it will be the last. And likewise for other 'last-something-wins' clauses in the spec. I don't have further counter-arguments. :) Let's leave NOTABUG.
*** Bug 571120 has been marked as a duplicate of this bug. ***
*** Bug 608996 has been marked as a duplicate of this bug. ***
*** Bug 624530 has been marked as a duplicate of this bug. ***