Hi Mathieu, As my regard to your comment #45, I did some minor changes for your further review. # tar tvf ibmpmlinux_3.2.2-1_20160302.tar -rw-r--r-- root/root 19472 2016-03-02 16:25 ibmpmlinux_3.2.2-1.debian.tar.xz -rw-r--r-- root/root 537644 2016-03-02 16:25 ibmpmlinux_3.2.2.orig.tar.gz -rw-r--r-- root/root 402482 2016-03-02 16:26 ibmpmlinux_3.2.2-1_ppc64el.deb Here are my responses to your detailed concerns: - Version for Ubuntu should be -0ubuntu1 rather than -1. This is important, since there isn't an ibmpmlinux package in Debian currently that we sync to ubuntu. Should there be, then it would be fine to ship a package with a version -1ubuntu1. The 'ubuntu' suffix denotes it is an upload for ubuntu. Answer: Adding a long string "ubuntu" in the version field is not a good idea. It unnecessarily expands a package file name, which could cause troubles everywhere. Particularly, PMLinux programs can work fine (compatible) for all Linux variants that we support (RedHat, SuSE, Fedora, Ubuntu, and PowerKVM). It seems no meaning to have PMLinux pakage with a "ubuntu" tag. - If you must use an internal revision number following a - in the filename for the include source tarball, then let's modify debian/rules to account for this. Either debian/rules should go extract the specific file needed for the version, or it should avoid that entirely and just extract any tarball named ibmpmlinux_*.tgz Answer: We have no special versioning need for PMLinux. The release-version format "r.r.r-v" that PMLinux adapted is popular for Linux platforms. By search, there exist more than a half pakcages without "ubuntu" in their version strings on Ubuntu 16.04 and apt/dpkg can handle properly at present. We hope to maintain the same if no change is mandatory. - Even the architecture name there is irrelevant if there won't be a build for other architectures. This would mean it's possible to remove all the variables aside from $package. Answer: We have other builds in rpm format for ppc64 Big/little Endians. The architecture mark is critical because PMLinux packages are "global" and "exchangable": For example, PMLinux's RPM package is supposed to work well on a Ubuntu system (if rpm tool installed). - override_dh_clean: rm -rf there will not do anything, it is unnecessary, since there will not be an ibmpmlinux directory to remove (since things are extracted to debian/tmp, which will get cleaned up automatically. Answer: Commented it out as per your suggestion. Thanks. - no need for preinst or postrm. Running verify or uninstall in postinst/prerm is most likely wrong. Answer: Not really. Those function blocks are necessary even if for a package that remains still after installed, not to mention that PMLinux is "dynamic" package. In PMLinux case: 1) preinst is to backup the old daemon programs for comparisons later in postinst for whether to restart the process(es) in upgrade. 2) postrm is to remove PMLinux's temporary data storage and flexible configurations etc generated/changed after installed that apt/dpkg are not aware of. Nothing above is handlable without those scriptlets. Apt/Dpkg can not handle the necessity of restarting old daemons in an upgrade, nor able to uninstall PMLinux with a upstart job after installed PMLinux with a service of systemd in the past (scenario: the user might rollback systemd to upstart, or vice versa). - It is just as easy (not to say easier) to not run them at all and ship the right files from the source of the package. Tuning configuration is fine, but we should not create new directories, symlinks, and such, since that short-circuits the package installation processes from apt and dpkg. They will handle package updates and removing files just fine. Answer: No. apt/dpkg can't do that fine, because PMLinux won't stand still after installed. PMLinux contains data-collecting daemons which do need to create a new directory for data storage under its home path. It is neither fine for tuning configuration. Configuration includes init service rollback or upgrade (upstart <-> systemd) which may result in file content & location changes that apt/dpkg can not manage at all. - In other words, if the source already ships all the right files (including a pre-made systemd service and reasonable default config), then all the maintainer scripts (postinst, preinst, prerm, postrm) can be removed. Otherwise, I would strongly recommend not keeping preinst and postrm. Postrm is completely unnecessary if the symlinks are done using dh_link (see below). Answer: Pre-made systemd is an impossible task. PMLinux.deb installation is a dynamic and adapting procedure. Nothing can be pre-made to fit such a blooming Linux world with so many dependencies. As answered above, systemd vs. upstart is one, PMLinux install vs upgrade is another, and many more, like etc/cron vs spool/cron, Ubuntu vs non-Ubuntu layouts, KVM Host/Guest vs LPAR VM ... an so on. For instance, early Ubuntu releases support upstart, while recent ones support systemd by default but can be rolled back to upstart. Therefore, a pre-made systemd service file will ruin PMLinux's compatibility for all Ubuntu releases. The maintainer scripts are required to handle up/down grades. - rather than doing symlinks in postinst/prerm; the links should be created using dh_links, a file debian/links will have to simply contain the source and destination for the symlinks to create. This is much easier to maintain anyway, as you only need to list the source and destinations for the symlinks. Answer: If symlinks can be created with daily popular commands, why we bother to use an internal "dh_link" whose usage is hidden in dark. - also, I suppose the PMLinux.8 manpage should be decompressed and let dh_installman deal with it in debian/rules, to get rid of this lintian warning: W: ibmpmlinux: package-contains-timestamped-gzip opt/man/man8/PMLinux.8.gz Answer: Fixed. The warning disappeared after gzipping with "-n9" (gzip -n9 PMLinux-deb.manual => PMLinux.8.gz).