Re: [MoM] Regarding status of fis-gtm-initial package
On 01/23/2012 11:20 AM, Andreas Tille wrote:
On Mon, Jan 23, 2012 at 09:46:05AM -0500, Bhaskar, K.S wrote:
##############################################
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 is what I guessed. However, it revials the following questions:
- Is it necessary to *untar* the tarball in the postinst or not?
(I guess not - why not just shiping the plain files inside the
package)
[KSB2] I just replied to another e-mail with two different approaches to
creating a Debian package.
- Where should this *temporary directory* should be placed.
Currently it is in /usr/lib/fis-gtm which is terribly wrong
for temporary directories. I'd say something like /var/tmp/fis-gtm
or something like this (I need to check whether debian packages
should contain files in /var/tmp or whether /var/lib should be
prefered)
[KSB2] Yes, under /usr/lib/fis-gtm is a terrible place for temporary
files! As the files in the GT.M binary tarball can all be deleted post
installation, the installation script can use mktemp -d to create a
temporary directory.
- What files *really* need to be in this directory (see my other
MoM mail)? My guess is that *.o files are not needed at all.
[KSB2] Again see my other e-mail about .o files.
[KSB] As part of the installation process, the script should be run
on the machine where a binary GT.M distribution is being installed.
I will just trust you here as the expert, but it would be interesting to
know what *exactly* needs to run on the target machine. I guess
untaring a tarball is not necessarily a part of this machine dependant
installation process. So the question is: Which part really needs to
be on the machine and which one not.
[KSB2] The "configure" script in a GT.M binary distribution does only
those things that need to be done on each target machine.
Please also consider the following problem: The fis-gtm-initial package
serves only one single purpose to bootstrap a "real" fis-gtm package (at
least this is what I have unerstood). So I wonder whether the initial
package which finally bootstraps the real thing could perfectly run on
any machine and rather the installation of the final package which is
intended to run in production needs to undergo the "install on very same
machine" procedure.
In other words: As far as I understood the issue in Debian we need a
package we can Build-Depend from to build the fis-gtm package targeting
at production machines. This Build-Dependency will run on any random
machine which is just running in a freshly created chroot of the build
machine. Do such special cases require the "should be run on the
machine where a binary GT.M distribution is being installed" feature?
It actually serves the single and only purpose to build the production
package and will be deinstalled later.
[KSB2] fis-gtm-initial should only be run on a machine on which GT.M
binary distributions are built from GT.M source distributions. And it is
only needed for th at very first single bootstrap. Once there is a GT.M
package, fis-gtm-initial is unnecessary. It is exactly the same problem
as gcc - you only need an initial special gcc for that very first
compilation of gcc. After that, you can use the gcc you built last time
to build the next gcc.
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!), ...
You can safely assume that I know that GT.M is cool and I do not want to
blame GT.M for beeing complicated but rather complex for whatever
reasons we do not need to discuss here. I just wanted to express to Luis
that packaging GT.M is very different to the vast majority of all Debian
packages (no matter what the reasons for this different are - we need
to cope with it anyway).
[KSB2] Well, GT.M could and should be much simpler, but it's the product
of an evolutionary process that we have to live with... Sort of the way
all of us live with a nervous system that doesn't always route nerves by
the shortest route but sometimes by a circuitous route that loops around.
And I am glad that Luis decided to jump in to what is clearly a very
complex package.
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: