Re: Any progress with FIS GT.M?
On Mon, 18 Jun 2012, Bhaskar, K.S wrote:
> If I understand correctly, you want to make these changes to avoid a
> postinstall script in the package. I have to ask whether this amounts to
> spending ten dollars to save one dollar.
It might indeed look like that, and if someone jumps in and crafts
the pre/post- scripts and they would not alarm Debian ftpmasters -- who
am I to say "no!"? ;)
Debian is a binary linux distribution and that is done for a number of
reasons going beyond the convenience of not dealing with
compiling/installing at package installation time (i.e. our 'stage2'
installation), e.g. such tools like 'lintian' do some verification of
the generated (during package build time) binaries to see if there are
no alarming/wrong linkage problems, unneeded/needed debug symbols etc
(btw -- ideally there could be fis-gtm-dbg package with debug symbols
;)). So, to take the most of advantage of Debian standartization and
tools, and avoid debugging post/pre- scripts (not the best experience)
I (once again -- personally) would prefer to spend 10$USD once
than pay 1$ possibly 100 times later ;)
> I still hope that we could find the relevant code where the
> filename gets embedded so we could either patch it simply to look for
> >...<
> [KSB] I'll see about getting you that information - it is possible that
> none of the developers knows that answer right off the top of his head and
> some research will be needed.
My wild guess is that it is in the op_zlink, in particular when dealing
with
zro_ent *srcdir, *objdir;
in particular with ->str field ;) I just rebuilt without stripping --
and will see if that is indeed the case on a tiny example...
> with you to enhance it. But changes in the core of GT.M should not be
> made lightly because there are twenty-six years of application code that
> runs on GT.M and which we cannot afford to break.
yes -- we better don't! but, even though not directly code-changes,
IMHO cmake-ification was already a HUGE disturbance which would warrant
extended testing to guarantee that things perform as destined.
> Changing the topic, I think the pre-remove script requires some thought
> and should be coded along the following lines, assuming that $gtm_dist is
> set to the directory of the GT.M release to be removed (if the environment
> variable is not set, the mupip command described below will not run):
> * Identify all the mumps processes that have $gtm_dist/libgtmshr.so
> open; execute $gtm_dist/mupip stop <pid> for each process.
> * Most processes will shut down immediately. In the unlikely event that
> any processes still remain at the end of ten seconds, issue a kill
> -KILL to those processes. (The pre-remove script should not wait ten
> seconds; it should simply wait up to 10 seconds.)
> * Identify all mupip, dse and lke processes that have
> $gtm_dist/libgtmshr.so open; execute $gtm_dist/mupip stop for each of
> them. In the unlikely event that any processes are still alive after
> ten seconds, kill -KILL them.
> * Execute $gtm_dist/mupip rundown (with no arguments).
> * If there is a $gtm_dist/gtmsecshr process active, issue it a
> $gtm_dist/mupip stop.
Thanks for outlining all those! May be: since (from what I understood)
all those GT.M instances are to be served by possibly different users
(right?) i.e. there is no system-wide control over
starting/stopping an instance(s) of GTM -- may be it would be wise just
to implement a check if anything of above actions need to be performed
-- and if so, abort installation/upgrade and seek admin/users manual
shutdown before the upgrade?
--
Yaroslav O. Halchenko
Postdoctoral Fellow, Department of Psychological and Brain Sciences
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Reply to: