[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [MoM] Regarding status of fis-gtm-initial package





On 01/22/2012 05:16 PM, Andreas Tille wrote:
Hi,

I had another look into fis-gtm-initial package and noticed that it
creates a deb package containing two (=both available) binary tarballs
contained in the source ball.  IMHO that's pretty useless and thus I
changed debian/rules to only install the tar which matches the
architecture that matches the build system.  Thus I've got a binary
deb which basically contains:

   /usr/lib/fis-gtm/distribution/gtm_V54002B_linux_x8664_pro-amd64.tar.gz

(in my case the amd64 binary) and a postinst file created by Thorsten
that seems to implement some installation magic.  I did not dived into
this but it fails for me:

...
Installation completed. Would you like all the temporary files
removed from this directory? (y or n)
... automatic configuration finished
##############################################
rmdir: failed to remove `TMPPOSTINST': Directory not empty
dpkg: error processing fis-gtm-initial (--configure):
  subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
  fis-gtm-initial
[KSB] The "Installation completed ..." question is part of the GT.M installation script. It is part of the GT.M binary distribution and expects to run in a temporary directory (anywhere on the system) where the GT.M binary tarball has been unpacked. At the end of the installation process, it asks whether the files should be deleted in the temporary directory.

This problem now goes into GT.M expert land.  I have no idea what is
needed to do the GT.M initialisation and I have not read the needed
docs.  So it seems somebody with GT.M knowledge needs to fix the
postinst file.

Remark: My gut feeling tells me that doing such complex operations
should not be done in /usr/lib/fis-gtm but rather in /var/lib/fis-gtm.
I'm also definitely not convinced that this should be done in the
postinst.  I really think whatever needs to be done there should be done
on the machine that builds the package.
[KSB] As part of the installation process, the script should be run on the machine where a binary GT.M distribution is being installed.

SO everything is kind of a gut feeling - but it seems something in the
current packaging is not done the way I regard it as most
straightforeward.  However, it might perfectly be that this is because
of the GT.M nature.
[KSB] It's not the nature of GT.M but the fact that that is the way GT.M does it. Since GT.M has been in production for twenty five years now (since before there was a GNU/Linux and before there was a Debian!), and the installation process has continuously evolved, I agree that it is not necessarily intuitive, since it cannot make assumptions that a package for a Linux distribution is allowed to make.

Regards
-- Bhaskar

Kind regards

         Andreas.


--
GT.M - Rock solid. Lightning fast. Secure. No compromises.

_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.


Reply to: