Bug#868431: wmaker: uses static upstream menu

[Andreas Metzler]

On 2017-08-13 Doug Torrance <dtorrance at piedmont.edu> wrote:
> On 08/07/2017 08:51 AM, Andreas Metzler wrote:
>> On 2017-07-29 Andreas Metzler <ametzler at bebt.de> wrote:
>>> On 2017-07-29 Andreas Metzler <ametzler at bebt.de> wrote:
[...]
>>>> #1 Providing a new full menu in /etc/GNUstep/Defaults/WMRootMenu does
>>>> not make the new content available to users. Anybody who has started
>>>> wmaker before will continue using ~/GNUstep/Defaults/WMRootMenu which
>>>> references "menu.hook". So I think we need to provide a file named
>>>> menu.hook in wmaker's search path with the new content.
>>> [...]
>>>> Afaict #1 only has an imperfect solution, shipping the menu in
>>>> /usr/share/WindowMaker/menu.hook.
[...]

>>> which does not seem to work, since with a WMRootMenu consisting of
>>> "menu.hook"
 
>>> wmaker expects the menu.hook file to contain a menu file in plain-text,
>>> i.e. non proplist format.
> 
>> Okay. Plan C (commited to GIT for review):
>> * Revert WMRootMenu to contain just "menu.hook".
>> * Convert dynamic menu to old style format and install it as
>>    /etc/GNUstep/Defaults/menu.Debian
>> * Symlink /etc/GNUstep/Defaults/menu.Debian to
>>    /usr/share/WindowMaker/menu.hook to let WMRootMenu use it.
>> * Ship dynamic plmenu in wmaker-common examples.

> I just submitted a patch upstream which would allow WMRootMenu to point to
> the new menu in proplist format.  If we include the patch, then we wouldn't
> need to ship both formats, and we could use your "imperfect solution" from
> above.

I am all for not shipping two formats, but also firmly believe that our
menu should live in /etc/.

> Is menu.hook (or whatever we end up calling it) really a configuration file?
> WMRootMenu definitely is, but there are tons of of other menu files already
> in /usr/share/WindowMaker.  These just serve as defaults/examples, and
> aren't configuring anything unless WMRootMenu points to them.

They are a little bit more than examples, they are also fallbacks if the
normal menu is unreadable.

> So I think
> there's an argument for putting menu.hook in /usr/share/WindowMaker,
> pointing WMRootMenu to it, and not violating policy.

I think that makes it unnecessary hard for a sysadmin to customize the
menu. If menu.hook lives in /etc [1] he/she just edits the menu and
stuff works. If not he/she needs to edit
/etc/GNUstep/Defaults/WMRootMenu *and* needs to make sure that
~/GNUstep/Defaults/WMRootMenu of every user is updated.

> Out of curiosity, why not use dpkg-maintscript-helper to remove
> appearance.menu and menu.hook as you did for wmappearance and menu-methods?

Afaiui dpkg-maintscript-helper only handles dpkg-conffiles.

cu Andreas

[1] With either a symlink in /usr/share reinstating
50_def_config_paths.diff to have it be used.

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'