Hi Bhaskar,
sorry that I have so much questions, but I really want to understand your
philosophy. I copied paragraphs from some of your latest mails and put my
question/comment below:
[KSB] I am not sure what you mean by "what other people choose".
(...)
So, there is no special GT.M user. Period.
I understand your statement, but on the other side there is your configure
script.
You added some code to input different userid and groupid. So there must
be at least somebody who wanted to have such feature. Further there are
your $rscripts (gtmstart gtmstop gtcm_run gtcm_slist) that always belong
to root independent of your input.
I might be a bit annoying, but I am full of curiosity why you implemented
it this way and for example don't always give ownership to root or any
other uid 0.
By my original question I just wanted to know whether other people keep
the default or create their own user/group although that is not
necessarily needed.
One wrinkle is that it is possible for users to have 32- and 64-bit
versions of GT.M to exist on the same system. So, the recommended
practice is to put _x86 or _x86_64 in the directory name under
/usr/lib/fis-gtm. Here is a listing from my laptop:
Hmm, is there any good reason why someone wants to have both versions
on a 64-bit processor? I have no problem to call the configure script
twice, but if nobody has any need for it, we could save some CPU cylces
on the buildd.
It
would also be good to have a way select the preferred GT.M version
(defaulting to the latest) through /etc/alternatives.
Yes, that is a good idea.
[KSB] If we can get GT.M into the repositories using the existing MUMPS
bootstrap, that will probably be less work than completing the Python
scripts.
But the existing bootstrap is only available for i386 and amd64.
Although I don't expect anybody to run GT.M on arm, there are other Debian
architectures being very appropriate for GT.M. Especially s390 seems to be
a good candidate, right?
[KSB] I am not sure where you get the idea of hundreds of releases.
Sometimes I exaggerate a bit :-).
Our
history over the last five years is that one series of releases went to
D. A couple went to B. Three went to A. The rest stopped at the base.
I just did a quick eyeball check - we have had 23 releases of GT.M over
five years.
Ok, even this seems to be quite a number. I guess currently the package
with the most versions is python (?) with about 4 versions in any
Debian release.
I understand that someone wants to install a special version that for
example has been certified by somebody. But why does one want to install a
B-version if there is a C-version available? As this is "only" a patch
version, everybody should spring at that version immediately!? With all
your tests you do before release, there should be no problem with an
upgrade.
There are scripts gtcm_server and gtmstart in which $logdir is set to
$gtm_dist/log. Do you plan to separate $logdir from $gtm_dist in some
future version? In Debian binaries and logfiles should not be in the same
directory.
Further, in your configure script you explicitly test for en_US.UTF8. Is
there any reason to deny all other UTF8 locales?
Thorsten
--
To UNSUBSCRIBE, email to debian-med-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/pine.lnx.4.64.1107251939110.16...@tor.gallien.in-chemnitz.de
