Here's a hint to make sense of the Lintian output:
Use: lintian -i mma*.deb
The -i gives detailed information about each "tag" it displays. Better than that, it also displays some clue as to how to solve the issue.
~/Desktop$ lintian -i mma_1.4_all.deb
W: mma: manpage-has-bad-whatis-entry usr/share/man/man1/mma-renum.1.gz
N:
N: Each manual page should start with a `NAME' section, which lists the
N: name and a brief description of the page seperated by '\-'. These
N: sections are parsed by `mandb' and stored in a database for the use of
N: `apropos' and `whatis', so they must be in a certain format. This
N: manual page apparently uses the wrong format and cannot be parsed by
N: `mandb'.
N:
N: For information on how `NAME' sections should be written see
N: lexgrog(1). See also groff_man(7) and groff_mdoc(7) for general
N: information on writing manual pages.
N:
W: mma: manpage-has-bad-whatis-entry usr/share/man/man8/mma-libdoc.8.gz
W: mma: extra-license-file usr/share/mma/text/COPYING
N:
N: All license information should be collected in the debian/copyright
N: file. This usually makes it unnecessary for the package to install
N: this information in other places as well.
N:
N: Refer to Policy Manual, section 12.5 for details.
N:
W: mma: package-contains-empty-directory usr/share/mma/includes/aria/
N:
N: This package installs an empty directory. This might be intentional
N: but it's normally a mistake. If it is intentional, add a lintian
N: override.
N:
W: mma: command-with-path-in-maintainer-script postinst:8 /usr/bin/mma
N:
N: The indicated program run in a maintainer script has a prepended path.
N: Programs called from maintainer scripts normally should not have a
N: path prepended. dpkg ensures that the PATH is set to a reasonable
N: value, and prepending a path may prevent the local administrator from
N: using a replacement version of a command for some local reason.
N:
N: Refer to Policy Manual, section 6.1 for details.
N:
W: mma: old-fsf-address-in-copyright-file
N:
N: The /usr/share/doc/<pkg>/copyright file refers to the old postal
N: address of the Free Software Foundation (FSF). The new address is:
N:
N: Free Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston,
N: MA 02110-1301, USA.
N:
E: mma: copyright-should-refer-to-common-license-file-for-gpl
N:
N: The strings "GNU General Public License" or "GPL" appear in the
N: copyright file for this package, but the copyright file does not
N: reference /usr/share/common-licenses as the location of the GPL on
N: Debian systems.
N:
N: If the package uses some other license that just mentions the GPL and
N: that Lintian should detect as an exception, please file a Lintian bug.
N: If the copyright file must mention the GPL for reasons other than
N: stating the license of the package, please add a Lintian override.
N:
N: Refer to Policy Manual, section 12.5 for details.
N:
W: mma: copyright-without-copyright-notice
N:
N: The copyright file for this package does not appear to contain a
N: copyright notice. You should copy the copyright notice from the
N: upstream source (or add one of your own for a native package). A
N: copyright notice must consist of Copyright, Copr., or the Unicode
N: symbol of C in a circle followed by the years and the copyright
N: holder. A copyright notice is not required for a work to be
N: copyrighted, but Debian requires the copyright file include the
N: authors and years of copyright, and including a valid copyright notice
N: is the best way to do that.
N:
N: If the package is in the public domain rather than copyrighted, be
N: sure to mention "public domain" in the copyright file. Please be aware
N: that this is very rare and not the same as a DFSG-free license. True
N: public domain software is generally limited to such special cases as a
N: work product of a United States government agency.
N:
N: Refer to
http://ftp-master.debian.org/REJECT-FAQ.html for details.
N:
W: mma: description-synopsis-might-not-be-phrased-properly
N:
N: The synopsis (first line in the package "Description:" field, the
N: short description) ends with a full stop "." character. This is not
N: necessary, as the synopsis doesn't need to be a full sentence. It is
N: recommended that a descriptive phrase is used instead.
N:
N: Note also that the synopsis is not part of the rest of the
N: "Description:" field.
N:
N: Refer to Policy Manual, section 3.4.1 for details.
N:
E: mma: changelog-file-missing-in-native-package
N:
N: Each Debian package (which provides a /usr/share/doc/<pkg> directory)
N: has to install a changelog file. Since this package seems to be a
N: native Debian package (i.e., there is no upstream source), the file
N: should usually be installed as /usr/share/doc/<pkg>/changelog.gz
N:
N: Refer to Policy Manual, section 12.7 for details.
N:
E: mma: essential-no-not-needed
N:
N: Having `Essential: no' is the same as not having the field at all, so
N: it just makes the Packages file longer with no benefit.
N:
N: Refer to Policy Manual, section 5.6.9 for details.
N:
With regards to the binary paths mentioned previously, any package shipped in a Debian-style package should have executables located directly off of / or /usr (as appropriate). /usr/local is reserved for the local administrator to use as desired. Debian packages should never put anything in that tree. This is actually mentioned in the Linux Filesystem Standard. Debian policy requires the packages to comply with the Linux Filesystem Standard.
To my knowledge, the package fails to comply with the Linux Filesystem Standard, as the package assumes the /usr tree is writable. -- The .mmaDB files should actually be located in /var/lib/mma. I may be wrong here, but it "feels" wrong to me. Anything that is generated and can be recreated should typically be in /var.
There's a whole separate package for the Python Policy.
http://www.debian.org/doc/packaging-manuals/python-policy/It should clarify exactly how the pyc files get processed. There is a standard process to handle this which will actually handle it for
all installed Python versions. This will include future Python versions that get installed between MMA upgrades. (Last I checked there were two valid options for this task, as they have two different tools to do the task.)
I'm not an actual Debian package maintainer, but I do create internal Debian packages for my job. This has given me more exposure to the tools than most.
I heard about the package because of the availability in Ubuntu's Universe repository. It definitely looks neat.
