Hi Andreas,
To explain further about the directory permission thing, when I built
the Debian package, I started by running GT.M's 'config' script,
installing GT.M into the directory /usr/lib/fis-gtm/V5.4-000A_x86. I
answered the installation questions as follows:
File owner: bin
Execution of GT.M restricted: no
Unicode support: yes
ICU version: 4.2
Lower case versions of MUMPS routines: no
The config script sets up the the following directories with 'r-xr-xr-x'
(i.e. not writable) permissions:
- V5.4-000A_x86
- V5.4-000A_x86/utf8
- V5.4-000A_x86/plugin
- V5.4-000A_x86/plugin/gtmcrypt
- V5.4-000A_x86/plugin/gtmcrypt/utf8
Additionally, some of these directories contain symbolic links. If I
build the Debian package and maintain the non-writable permissions on
the directories, when someone wishes to extract the package (dpkg -x)
without root privileges, they get errors because the directories do not
have write permission. So what I did was change the permissions on
these directories to rwxr-xr-x in the Debian package. When the actual
install occurs, the 'postinst' script does a chmod to put the
permissions on these directories back to r-xr-xr-x. I took this step
because Bhaskar had requested that the package be extractable without
root privileges.
You mentioned that I should not rely on the user ID of any user. I was
concerned about that too, which is why I placed the two following
commands at the end of the postinst script:
chown -R --from=0:2 root:$owner "$version"
chown -R --from=2:2 $owner:$owner "$version"
On my system, the value of '2' is assigned to user bin and the value of
'0' is assigned to root. (I suspect root is always assigned the value
of zero, but just in case... :) This way, I ensure that the ownership
is correct, regardless of the value assigned by a particular system.
Regarding 'svn://svn.debian.org/svn/debian-med/trunk/packages/gtm/trunk'
and the GT.M scripts that I referenced, I wasn't trying to get into too
much detail about them right now. (I wouldn't mind doing it, but I
didn't want to muddy the waters.) I was just wondering whether everyone
was okay with the idea of using update-alternatives to link the Fidelity
supplied script of '/usr/lib/fis-gtm/V5.4-000A_x86/gtm' to the name
'gtm-su' (instead of simply 'gtm'). My thought is that since the
Fidelity supplied script named 'gtm' uses a database that is in the
user's home directory, it's more similar to a single-user version of
GT.M (i.e., if the system is setup so different users cannot access each
others home directory, then effectively GT.M becomes single user). So I
thought it might be good to rename that script, so to speak, as "gtm-su"
(single user) and then later publish a script called "gtm" that allows
users to enter a specific GT.M environment that is accessible to
multiple users.
I definitely agree that it's tough with just the postinst script. I'd
be happy to share more, but I need some help on that front.
Specifically, I'm wondering what is the preferred method for sharing the
other details. I'm thinking -- perhaps incorrectly -- that it would not
be the best approach to upload the whole package to the Debian Med
list. (Sorry, I have to admit that I've not used list serves much in
the past.) If you could give me an idea on the best way to share the
details of the package, it would be great. :)
Thanks much for your thoughtful response. I look forward to hearing
from you again soon.
Alan
--
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/4c7ad33e.5080...@cavtel.net
