Bug#832941: RFS: 4pane (debian: to exclusive)
Dear Sean,
Many thanks for your further input.
>Here's another review, based on your 4pane-debian-dir repo.
>Must-fixes
>1. At least one of the files added by AddExtraM4Files.patch isn't accounted
>for in d/copyright.
//snip
>9. Lots of files in .build/ are not accounted for in d/copyright.
Thank you. I'd completely forgotten about copyright for bitmaps/ and hadn't
considered it for debian/.
Many of the bitmaps were acquired in 2004/5 and I didn't record where from.
After spending a lot of time tracing them I believe d/copyright is now correct.
>2. Vcs-* still point to the upstream code, not your 4pane-debian-dir repo.
I'd thought that repo was just for the purpose of this review. However I've
corrected that now.
>8. Further, could you confirm that, for the files in bitmaps/ and the
>images in doc/ whose preferred format for modification is not .png, the
>.xpm/.svg/whatever source is available? I see some .xpm/.svg files but
>not for every file. If the preferred format for modification for those
>other files is editing the .png then it's fine.
There is no other source. I confirm that if I or anyone else wished to modify
a .png, editing it would be the preferred method.
>10. .build/DONT_README (heh) explains that the Bakefile tool is required
>to regenerate the build system. I.e. the preferred format for
>modification of the buildsystem is not by editing Makefile.in, but by
>changing some other files and running Bakefile
No, that's the way that Makefile.in was initially created, and it would be a
convenient way to make major changes to it. But most of the time I edit
Makefile.in by hand (as I just did when removing some unused bitmaps) and for
normal building, even with dh_autoreconf, bakefile itself is irrelevant.
>(is Makefile.in the only file that Bakefile outputs?).
There are also the 3 .m4 files in AddExtraM4Files.patch, which _are_
needed for dh_autoreconf.
>As before, this is a violation of DFSG. I think you need to package
>Bakefile for Debian, unless you can think of a way around this.
As above I don't believe that's necessary. I'd add that bakefile was created
for the wxWidgets toolkit, which uses it far more often than does 4Pane. Yet
the wxWidgets packages e.g. libwxgtk3.0-dev don't include bakefile and their
maintainers presumably don't feel that violates DFSG.
>11. You need to run dch -r to refresh the changelog timestamp so it is
>after the various changes you've made recently.
Done
>Suggestions
>-----------
>
>1. You might raise the debhelper compat to 10, the latest version. That
>means you can drop '--parallel --with autoreconf' which are automatic at
>compat 10.
Done.
>2. At the top of d/rules you define various EXTRA_ env vars. Could you
>explain further why you can't do this "the standard way"? Would it be
>possible to make it work by patching the upstream Makefile? Generally
>speaking, it's better to have a short d/rules and move logic into the
>upstream Makefile (otherwise someone trying to understand it has to flip
>back and forth between two files).
I see what you mean. I've now done so.
>3. In a previous e-mail I explained why I think it would be clearer to
>call the wxWindows license "GPL-2+ or wxWindows-3.1+". So far as I can
>tell you never responded to that -- please consider the points I made.
>Unless I'm missing something, it would make d/copyright clearer.
I think I did, but anyway:
In wxWindows circles the licence is invariably referred to as the wxWindows
one, often with the explanation that it's GPL-2 plus an exception. It's also
used in the libwxgtk3.0 packages' d/copyright. However I don't have any
expertise in such things and I'm happy to change it if it's thought necessary.
>4. You should probably s/4pane/4Pane/ in 4pane.doc-base.
Done.
>5. Rather than installing 4Pane.desktop twice, you could do something
>like this:
>
> override_dh_install:
> dh_install
> ( cd debian/4pane/usr/share && mv 4Pane/rc/4Pane.desktop applications )
Done.
>6. It's definitely not wrong, but it might not be optimal. What I'm
>imagining is the following situation: Debian users expect to find
>certain files (changelogs, copyright files) in /usr/share/doc/foo.
>Since 4Pane is known as '4Pane', a user might reasonably look in
>/usr/share/doc/4Pane. But then they wouldn't be able to find the
>standard files. For this reason, I think /usr/share/doc/4Pane should be
>a link to /usr/share/doc/4pane and 4Pane can be patched to find its help
>files there.
Done.
Regards,
David Hart
Reply to: