Re: [MoM] Regarding status of fis-gtm-initial package
On Mon, Jan 23, 2012 at 11:36:52AM -0500, Bhaskar, K.S wrote:
> [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.
Well, from a packagers perspective you should not delete what you once
have installed because the packaging mechanism wants to remove
everything that was installed before. So it is a good idea to keep the
files that come with the package. In so far my suggestion to keep the
untared files inside the *.deb package is questionable because they
need to remain. Perhaps this was Thorsten's motivation to just store
the tarball. So the option would be to do the following:
1. tarball into /var/lib/fis-gtm/distribution
2. in postinst do:
tar -xzf /var/lib/fis-gtm/distribution/*.tar.gz
rm -rf $FISUNPACKDIR
Does this sound reasonable?
> [KSB2] The "configure" script in a GT.M binary distribution does
> only those things that need to be done on each target machine.
So this is the run_whatever_command_needs_to_be_run command above?
> >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.
This seems to be the same statement as I tried to give above with
probably better words.
> And I am glad that Luis decided to jump in to what is clearly a very
> complex package.
Yep. Thanks for your brave attempt