Updating packages from 1.6.x to 1.8.x
An overview on the status of MATE in Debian is given here
The update of packages from the 1.6.x series to the 1.8.x is shown here at the example of the mate-desktop package:
Update debian/watch: The tarball source we use has changed for MATE 1.8. Check this example for a MATE component that contains non-DFSG files. For packages that do not require repacking of the upstream tarball, simply omit the opts= line.
Drop dh-autoreconf build mechanism. Switch to using autogen.sh
Now try to build the package in a clean chroot (with pbuilder, sbuild). The next step is: Get the package to build again.
Check DFSG compliance
- If your package's upstream version contains "+dfsg", please check if repacking is still necessary. Check debian/rules's get-orig-source. What files/folders get removed to make the tarball DFSG-clean. Do these rules still apply to the latest upstream release.
- If your package's upstream version does not contain "+dfsg", please check if the new upstream release has added files, that are not appropriate for being shipped in Debian main. (e.g. GFDL licensed files, as found in mate-desktop/user-guide.
A good resource about repacking techniques is Dmitry Smirnov's get-orig-source wiki page on this site.
Update copyright file
Adapt debian/copyright to new MATE upstream component version. See this example.
The work on debian/copyright is normally quite an effort. And a well written debian/copyrights file is often the crucial point when uploading NEW packages to Debian. Most REJECTs by the ftpmaster team are related to wrong/incomplete/bad copyright files. Thus, it is good to take writing copyright files as a serious business.
Update symbols files for library packages
If new symbols have been added to a shared library, these new symbols should go into the libraries debian/<sharedlib>.symbols file.
During a package build, the tool dpkg-genchanges is run. It generates a patch for all not-up-to-date symbols files in a src:package.
Apply this match and remove Debian revisions from the version string of those new symbols manually after applying the patch.
See this URL for an example.
After test builds of a package, you can use the lintian tool to test the src:package's and bin:packages' integrity:
$ lintian -iIE --pedantic --show-overrides --color auto <package>_<architecture>.changes
The basic rule is, get the build result of the package as lintian-clean as possible.
Ask yourself the following:
- Do I have lintian overrides that are not used any more? If so, drop them.
- Is there a lintian issue that is intentionally there? If so, add a new override.
Some MATE packages still bundle all debugging information in one separate package.
Split up the single <package>-dbg package into several -dbg packages (one per bin:package)