Dear Maintainer,
Thank you for maintaining wmaker. I was upgrading wmaker when noticed
this by adequate. Please fix this.

[$] adequate wmaker

wmaker: missing-alternative x-window-manager

Looking forward for the fix.

Control: affects -1 adequate

Thanks for your report!

As far as I can tell, Window Maker does properly register with
update-alternatives.  For example, on my system:

profzoom@cayke:~$ update-alternatives --list x-window-manager
/usr/bin/icewm
/usr/bin/notion
/usr/bin/openbox
/usr/bin/wmaker
/usr/bin/wmii

I took a look at the code to adequate, and it appears that it double
checks whether the path registered with update-alternatives is shipped
in the corresponding binary package.

However, /usr/bin/wmaker is actually a script which creates some
directories and copies some files if needed before actually running the
actual window manager (/usr/lib/WindowMaker/wmaker).  Since it's an
architecture-independent script, it is shipped in the wmaker-common
package, not the architecture-dependent wmaker package.

This appears to be the issue.

I'm not sure if this is a bug in Window Maker, a bug in adequate, or
something that can be safely ignored.

I'm adding adequate to the 'affects' for this bug for its maintainers'
input.

Doug

Control: reassign -1 adequate
Control: retitle -1 false positive wmaker: missing-alternative x-window-manager
[...]
[...]
[...]

... and wmaker depends on wmaker-common. The alternative is managed by
the wmaker package. So afaict there is no bug on the wmaker side. If
(and only if) wmaker is installed, the alternative will be present (and
working).

cu Andreas

hi folks,

new adequate maintainer here. thanks for filing the bug and for looking into it.

I think that either case could be made as to whether this is a bug in adequate
or in wmaker (imho the Debian policy is open to interpretation in this regard).
arguably, adequate is being rather pedantic by requiring that the registered
program be included in the binary itself, rather than via a direct dependency of
the binary. on the other hand, I see no practical value to ship /usr/bin/wmaker
in wmaker-common, given that /usr/bin/wmaker is:

- a wrapper around an executable in wmaker
- a 2 kb script so it really doesn't matter whether we ship it separately for
  every arch

Doug, would be okay with moving /usr/bin/wmaker from wmaker-common to wmaker?
that'd also allow you to drop the no-manual-page lintian override in
wmaker-common (currently needed b/c the script is in wmaker-common but wmaker(1)
in the wmaker package)

thanks,
Serafeim

On Tue Jul 23, 2024 at 2:23 AM CEST, Serafeim Zanikolas wrote:
[..]

I'm reassigning back to wmaker, and will also add a missing-alternative
exemption for wmaker in adequate (given that it's a known, low-severity issue)

thanks,
Serafeim