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