gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] Re: GNUmed needs your help


From: Andreas Tille
Subject: [Gnumed-devel] Re: GNUmed needs your help
Date: Fri, 30 Sep 2005 14:08:39 +0200 (CEST)

On Fri, 30 Sep 2005, Ian Haywood wrote:

Wouldn't dream of it.
It is in any case easier to bother you directly via this list.

Well, filing bug reports against Debian packages is allways a good idea.
It works the way to contact me directly for GNUmed and I do not really
want to change this, but in general it would make sense to use the
reportbug programm to report problems.

What I could reasonable do is just to prepare GNUmed for Python 2.4 and add
an explicite Python2.4 dependency to the package.  This should also work
for
Sarge users which should have Python 2.4.1.  What do you think about this?
Could we not have a simple dependency on python of any version greater than 2.1

You might have observed that many Python modules come in single packages 
supporting
several Python versions.  Random example:

$ apt-cache search python numeric-ext
python2.1-numeric-ext - Extension modules for Numeric Python
python2.2-numeric-ext - Extension modules for Numeric Python
python-numeric-ext - Extension modules for Numeric Python
python2.3-numeric-ext - Extension modules for Numeric Python
python2.4-numeric-ext - Extension modules for Numeric Python

The idea of these modules is that they install files in

    /usr/lib/python<VERSION>/site-packages

and thus are available for applications that use a specific Python
version.  The maintainer has to build (in the case above) 4 different
binary packages containing the very same files but installing them in
different directories.  The rationale behind is that at package installation
time all modules will be precompiled for faster loading and the result of
the compilation can be used only with the Python version that was used
to compile this binary code.  (The package without a version number
is nearly empty and just depends from the package that matches the default
Python version.)

This makes sense for modules which are needed for *several* applications
that might depend from a specific Python version.  If I have a *single*
application it does not really make sense to build several binary packages
for the different Python versions, because this application should
just *run* and does not provide functionality for other applications.
So I have to decide - that's what I did, or rather I left the decision
to the packaging system to use "the default".

BTW, using an explicite Python 2.3 dependency should work for Ubuntu as
well -
at least I hope that also a Python 2.3 package is provided.
Yes.

Perhaps an even more simple solution came into my mind.  You could just fake
the Dependencies using the equivs package.  I can not try this out on my
machine but if you report me the results we could do something about it.
Please try the following:

   $ sudo apt-get install equivs

Create an equivs control file names gnumed-client-python.ctl with the
following content:

-------------------------------- >8 ------------------------------------
Section: misc
Package: gnumed-client-python
Provides: python
Depends: python2.3
Description: Enables installing gnumed-common under Ubuntu
 Try to circumvent the higher Python default version on Ubuntu
-------------------------------- 8< -----------------------------------

Then do

   $ equivs-build gnumed-client-python.ctl

(Wow, you now builded you first Debian package. Congratulations! ;-) )

   $ sudo dpkg -i gnumed-client-python_1.0_all.deb

This depends from python2.3 package.  In case you have not installed this
before, the installation will fail and you can fix this using

   $ sudo apt-get -f install

(I hope you enabled /usr/bin/dpkg and /usr/bin/apt-get for sudo usage - if not
 you have to do this as root, but sudo is *very* convinient and I highly suggest
 to use it this way.)

Now your system might be prepared to install gnumed-common, because now the
Dependency python is provided by this equivs package.  I have no experiences 
with
equivs and it will probably be necessary to fiddle around with the control file
to fix the explicite versioned dependency.  Perhaps Google will help you if you
ask him for "equivs versioned dependency".  But for the first shot we can try 
this.
This would put some extra work on the Ubuntu users and not on me, which IMHO is 
a
fair deal, isn't it. ;-))

Kind regards

         Andreas.

--
http://fam-tille.de




reply via email to

[Prev in Thread] Current Thread [Next in Thread]