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

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



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)
  - 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)
  - 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.
 
> [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.

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.

> >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).

Kind regards

    Andreas.

-- 
http://fam-tille.de


Reply to: