Re: debian-med newbie seeks advice on where to place packages
On Tue, Aug 11, 2009 at 06:52:24PM -0400, K.S. Bhaskar wrote:
> 1. Multiple releases (or versions the terms are interchangeable) can and
> usually do coexist on the same system at the same time. So, we will
> have to use the version to identify each GT.M. So, we will need
> directories with names like .../gtm/V5.3-003_i686,
> .../gtm/V5.3-004_x8664, etc.
Having several versions of a package installed is no problem. There
are several prominent examples here like for instance gcc. If I understood
things correctly there are more similarities for GT.M with gcc (the
bootstrapping issue). When packaging different versions you should
make sure that all of them provide a common virtual package like:
Provides: mumps
(or gtm / mump-compiler / gtm-compiler ... whatever feels reasonable
to you).
The rationale is that you are able to build packages that depend from
GT.M by just specifying
Depends: mumps
in case they do not require a specific version per se and this dependency
gets fullfilled by any of the existing gt.m versions. In the gcc case
it is solved by "Provides: c-compiler".
> [Note: the initial releases will all be
> i686 binaries; at some point after the sources are properly repackaged
> and released, there will also be x8664 binaries.]
Two questions here:
1. Are you sure that there is a need to install binaries for more than
one architecture on one maschine. While this might be possible
with multiarch support I do not think that it is really intended
here and you might consider droping the architecture from the
directory name.
2. I think when you write x8664 binaries you mean what is called amd64
in Debian (and yes, also Intel chips are supported under this name).
> 2. GT.M is not one executable. Rather it is several: mumps, mupip, dse
> and lke are the main ones, but there are others. They all expect to
> reside in the same directory; otherwise they will not be happy.
That's perfectly fine. Normally binaries go to /usr/bin - so they are
in the same directory. In your case it sounds reasonable to put them
under /usr/lib/gtm-<version>/bin (or /usr/lib/gtm/<version>/bin if you
prefer and use a wrapper which sets the PATH variable to the wanted
directory. Providing symlinks to /usr/bin for the default version of
GT.M is an option as well.
> My tentative conclusions:
>
> 1. I should use directories with names like /usr/lib32/gtm/V5.3-004_i686
> each of which contains a complete GT.M release.
Rather
/usr/lib/gtm/V5.3-004_i686
/usr/lib64/gtm/V5.3-004_amd64
(/usr/lib32 is just /usr/lib) and as I said above I don't know whether
you need to specify the architecture in the version directory but it
does not harm IMHO.
> 2. For log files, I should use directories with names like
> /var/log/gtm/V5.3-004_i686.
Yes.
> 3. I should create executable files such as
> /usr/bin/mumps_V5.3-004_i686, which will contain something like:
> #!/bin/sh
> source /usr/lib32/gtm/V5.3-004_i686/gtmprofile
> /usr/lib32/gtm/V5.3-004_i686/mumps
If you leave the '32' behind 'lib' yes. You might also consider
using something like:
#!/bin/sh
export PATH="/usr/lib/gtm/V5.3-004_i686":"$PATH"
source gtmprofile
mumps
if this reduces "porting" your scripts to include only the PATH line.
But be careful: This "source gtmprofile" seems like you were reading
some machine specific configuration file. All configuration in Debian
goes to /etc. So what you rather might intend is:
source /etc/gtm/V5.3-004_i686/gtmprofile
Files in /usr are not to be changed by the local admin. If there
is a need that the file gtmprofile has to be in the GT.M directory
you have to do a
ln -s /etc/gtm/V5.3-004_i686/gtmprofile /usr/lib/gtm/V5.3-004_i686/
(see man dh_links for doing so).
> There will be similar files like /usr/bin/mupip_V5.3-004_i686 for the
> other executables.
That's fine.
> 4. I should create symbolic links such as /usr/bin/mumps that point to
> /etc/alternatives/mumps which in turn will point to a file like
> /usr/bin/mumps_V5.3-004_i686.
Yes. Have a look into update-alternatives (and probably other packages
like gcc-*) how this is done correctly.
> 5. Using the Debian alternatives system, I should provide alternatives
> to gtm so that /etc/alternatives/{mumps,mupip,dse,lke} are all switched
> at the same time to point to the selected GT.M version.
Yes.
> Some questions, please:
>
> 1. Does the directory layout above make sense?
In principle yes (modulo my remarks)
> 2. Where can I find documentation on creating a configuration for the
> Debian alternatives system? All I have found so far is instructions on
> using it, not on setting up alternatives for use.
I formerly had no need to use this so I have no idea whether there is
a better place to look than
man update-alternatives
I always like to have a look in other packages which are using the same
technique (for instance gcc, perhaps you just look into /etc/alternatives
which more simpler packages use it as well).
> 3. There is a small part of GT.M that must be owned by root and
> installed with the setuid bit on. Is there a special procedure for this
> or should I just do that in the postinstall script?
As far as I know postinstall script is the right place to do this. Please
anybody correct me if I'm wrong.
> 4. GT.M requires the ability to execute dynamically compiled code (it's
> a feature of the MUMPS language). To give GT.M this permission with
> SELinux, the usual installation of GT.M executes a command such as chcon
> -t texrel_shlib_t libgtmshr.so. But this presumes that SELinux is
> installed and operational. If SELinux is installed or configured later,
> this command will need to be run at that time. Is there a way to tell
> the Debian package manager, "if SELinux is installed or turned on, run
> this command"?
Hmmm, IMHO this is a question which should be directed to the debian-mentors
list. You do not need to subscribe any Debian list - but make sure you
observe the list archive for answers to your question because people might
forget to CC you (even if you ask explicitely to do so). I have never
dealt with SELinux stuff and do not know a reasonable answer.
Remark to Daniel's mail: I perfectly agree that short names (for packages
and binaries) tend to name space pollution. While I checked that there is
not yet a gtm package I missed that the gtml package has a gtm binary. If
I understood you correctly the GT.M binaries are not named gtm so this would
be no actual conflict - but using more verbose names is always a good idea.
So probably your suggestion fis-gtm is OK and I really like mumps-gtm
because this sounds reasonable for an implementation of MUMPS somehow.
But finally it is your choice as the maintainer to find a proper name.
Kind regards and thanks for your effort to package GT.M
Andreas.
--
http://fam-tille.de
Klarmachen zum Ändern!
Reply to: