Re: packaging review (lintian clean)
On Mon, Dec 2, 2013 at 1:37 AM, Robert Ames wrote:
> 1) Is the use of tempfile here correct? (is this properly secure / policy compliant? should it be in /var/run? but /var/run requires permissions issues)
The manual page for tempfile says that it is deprecated in favour of
mktemp. Otherwise ok. Since this is a PID file, I would suggest /run
instead.
> 2) Control file - does this look right? I removed the initial ${misc:Depends} which I'm assuming was from *.substvars? Is there more specific documentation on control-file syntax? Does everything else look right?
Since you are using debhelper, you need ${misc:Depends}, which is
indeed a substvar. debian/control files are documented in the
deb-control(5) manual page and in Debian policy.
http://www.debian.org/doc/debian-policy/ch-controlfields.html
> 3) Not checked in are: debian/files, debian/*.substvars, debian/*.debhelper.log ... are they required, or transitory?
They are all generated during the build, run `debuild -S` or
`debian/rules clean` or `git clean -dxf` to clean them out.
> 4) Use of debian/README.md as double/triple-duty (manpage, documentation, github initial page)... i'd prefer to have it at top level, but i think debian likes to have it in the debian directory. Is there another project I can look at which is doing this successfully? I don't want to use symlinks, but I'd prefer to have it in one place.
There is no need to have both the manual page and README.md in the
binary package. Debian doesn't care where you place README.md. Indeed
since it isn't strictly part of the packaging, more part of upstream,
the top level dir would be best.
> 5) This package is technically targeting "raspbian" in that it solves a specific issue related to HDMI ports and screensaver on Raspberry PI machines. I have an architectural question listed in the README at the end: this is working around "some issue" that is normally handled somewhere else in the software stack. Is it an HDMI/kernel issue that the port isn't deactivated? Is it xscreensaver that should be deactivating the port? I don't know enough about the "deepness" of the issue to make a better decision than pulling together this package.
I expect it is either the proprietary non-free binary blob running on
the main processor (on the RPi the ARM processor is just a slave to
the GPU) or the version of Linux you are using.
PS: your time might be better spent buying a more open and less hyped
device that is armhf capable:
https://wiki.debian.org/RaspberryPi
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: