#8133 (Bug) Incorrect postinst, postrm and control files in Ubuntu package

+1 1

Closed as Fixed
Component: 3.3.2
Created by

Last modified


This is actually three bugs and a feature request, but since they all relate to .deb file packaging, I thought I would bundle there here. I can split to separate issues if you prefer.

I tried installing the DisplayCAL package provided on the web site for Ubuntu 16.04. I'm actually running KDE Neon (based on Ubuntu 16.04), but the issues at hand are most likely not dependent on that. The downloaded file is displaycal_3.3.2.0-1_amd64.deb, with md5sum fa06fb95ba4e4b284c675f2f5faeee7a.

I used dpkg-deb -R to extract the .deb file contents, notably to have a look in the DEBIAN directory that contains the install scripts.

  1. Somehow, even though the project source code contains a corrected postinst script (with /usr/share/DisplayCAL paths), the .deb package itself still contains a postinst script that uses /usr/share/dispcalGUI. This prevents the udev symlinks from working. Maybe some stale files on a build server?
  2. The postrm script seems incorrect to me: inside the loop, it tests if the file does not exist and then if it exists and is a symbolic link, tries to remove it. The first test should simply be reversed.
  3. The control file lists a dependency on p7zip, but DisplayCAL actually runs the 7z command, which is in the p7zip-full package. Besides, the p7zip package only provides support for .7z files, and looking briefly at the source code, DisplayCAL seems to need support for other kinds of archive formats.

Finally, here is a related request: the control file lists a dependency on argyll, which means the corresponding Ubuntu package must be installed. Graeme Gill does not like those packages (and they are indeed outdated), and encourages users to install ArgyllCMS manually. I believe it there would be more flexibility in changing the argyll dependency to a Recommends dependency. For users with default settings, this would not change anything (recommended packages are automatically installed); more advanced users would be free to not install the package and do a more up-to-date manual install.


3 thoughts on “Incorrect postinst, postrm and control files in Ubuntu package”

  1. Somehow, even though the project source code contains a corrected postinst script (with /usr/share/DisplayCAL paths), the .deb package itself still contains a postinst script that uses /usr/share/dispcalGUI. This prevents the udev symlinks from working. Maybe some stale files on a build server?

    Indeed, a stale file on OBS. Thanks for noticing, rebuilds are underway.

    The postrm script seems incorrect to me: inside the loop, it tests if the file does not exist and then if it exists and is a symbolic link, tries to remove it. The first test should simply be reversed.

    My understanding (correct me if I’m wrong) is that the -e test follows symbolic links. So if the file is a symbolic link and the actual file the link points to does not exist, the symlink is removed, and this is the intention.

    looking briefly at the source code, DisplayCAL seems to need support for other kinds of archive formats.

    No, DisplayCAL only uses 7z if available and falls back to other formats it can create natively otherwise (apart from a small part of the code that isn’t really used any longer due to workflow changes). I should probably remove the dependency altogether.

    Finally, here is a related request: the control file lists a dependency on argyll, which means the corresponding Ubuntu package must be installed. Graeme Gill does not like those packages (and they are indeed outdated), and encourages users to install ArgyllCMS manually.

    This dependency originates from a time when auto-download of the latest tested Argyll release was not implemented in DisplayCAL, and could possibly be removed altogether. I’ll change it to a “Recommends” for now.

    1. My understanding (correct me if I’m wrong) is that the -e test follows symbolic links. So if the file is a symbolic link and the actual file the link points to does not exist, the symlink is removed, and this is the intention.

      You are correct, I misunderstood the test.

      DisplayCAL only uses 7z if available (…) apart from a small part of the code that isn’t really used any longer due to workflow changes

      If I followed correctly, you’re talking about the part where you extract some files from .cab / .exe files? Anyway, as long as DisplayCAL makes use of the 7z command on Debian and Ubuntu distributions, it should depend on pz7zip-full (or Recommend or Suggest that package).

      The p7zip package only provides the 7zr command.

  2. Anyway, as long as DisplayCAL makes use of the 7z command on Debian and Ubuntu distributions

    It doesn’t though. The “natural” format created under Linux is tgz.

Comments are closed.