[Debian-med-packaging] Bug#449440: severity is important

[Steffen Moeller]

On Monday 05 November 2007 23:05:43 Karsten Hilbert wrote:
> On Mon, Nov 05, 2007 at 10:52:00PM +0100, RKI Andreas wrote:
> >> severity 449440 important
> >
> >     a bug which has a major effect on the usability of a package, without
> >     rendering it completely unusable to everyone.
>
> Precisely, that's what it does.

To clarify for others reading this thread. gnumed-common depends on 
python-support >0.7.1, but etch has something around 0.5. Consequently, 
gnumed-common cannot be backported automatically to stable. At least it looks 
like this at first sight since the binary package cannot be installed as it 
is.

> > Please remind: Something that might be important for your day to
> > day work might have a really different importance for Debian as
> > a distribution.  In this scope it is important to keep a system
> > _stable_ which means = no new versions.
>
> I don't in the least ask for a new version of GNUmed in
> Debian/Stable. First of all I ask for a consistent
> explanation of why gnumed-client 0.2.7.1 cannot be installed
> into a Stable system while 0.2.7.0 can.
>
> The only dependancy change between those two versions was
> #447405 which removed python-pgsql and added
> python-psycopg2.

The dependency is not hard-coded:
http://svn.debian.org/wsvn/debian-med/trunk/packages/gnumed-client/trunk/

Package: gnumed-common
Architecture: all
Depends: ${python:Depends}, ${misc:Depends}, python-psycopg2
Pre-Depends: adduser


> Would that be the reason ?
Maybe there is none? The build depends are at 0.3.8

control:Build-Depends-Indep: po-debconf, python-support (>= 0.3.8), 
python-all-dev (>= 2.3.5-11)


> If so I wish to revert that fix because it worked before
> that - the fix was merely cosmetic.

Just try building it on a stable-run machine. I presume the problem is with 
the automated detection of dependencies for the binary. But I do not know 
enough about how python works. Maybe the dependency for the binary is correct 
and the compatibility depends on with which version the package was actually 
built.

Of course there is no right for a Debian package submitted to unstable/testing 
to be installable for stable rightaway. Hence, there is nothing to fix, 
technically speaking. This does not mean that with some spare energy and 
because one was kindly asked one could not possibly investigate further what 
happened. I personally dislike the idea to now go in and manually edit they 
versioning. backports.org might come to the rescue if the dependency is 
right, the version assignment should be fixed if the dependency is wrong.

Steffen