Bug#868431: wmaker: uses static upstream menu

[Doug Torrance]

On 08/13/2017 08:22 AM, Andreas Metzler wrote:
> 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.

Sounds good.  I've added the patch and removed the old-style menu in git.

>> 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.

Ok, that makes sense.  I deleted the blurb in d/changelog about deleting 
all the maintainer scripts.

Have a good one,
Doug