Re: debian-med hint (debcheck results)
- To: Debian Med Project List <debian-med@lists.debian.org>
- Subject: Re: debian-med hint (debcheck results)
- From: Andreas Tille <tillea@rki.de>
- Date: Thu, 22 Nov 2007 07:47:16 +0100 (CET)
- Message-id: <Pine.LNX.4.64.0711220735470.28795@wr-linux02>
- In-reply-to: <1195660395.6424.6.camel@localhost>
- References: <1195660395.6424.6.camel@localhost>
[Daniel, I hope that you do not feel that forewarding your mail do Debian-Med
list violates your privacy - it is just an important hint I want to discuss
openly.]
On Wed, 21 Nov 2007, Daniel Leidert wrote:
Just a short note (maybe it's interesting for you; but maybe you already
know about it, but ignore it).
We ignored it for the only reason because we was not aware of it - many thanks
for the hint.
I looked at [1] today and saw, that
debcheck reports afew problems. One of them is, that a few packages
suggest/recommend/depend on binaries, that are not available for all
architectures. In this case, you can dd an architecture in the form of
(say for e.g. [2])
Depends: [..], python-uno [amd64 i386 powerpc sparc], [..]
Recommends: [..], openoffice.org-writer [amd64 i386 powerpc sparc], [..]
[1] http://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org
[2] http://qa.debian.org/debcheck.php?dist=unstable&package=gnumed-client
At first I have to admit that I'm a little bit astonished that a package
can move to testing if there are missing dependencies for certain architectures.
In fact, if you look at
http://qa.debian.org/debcheck.php?dist=testing&package=gnumed-client
you see that the package has the same problems there.
For the specific GNUmed problem I wonder what would be the right strategy:
Solving the problem as suggested above or (intentionally) ignore the problem.
On one hand I do not like open problems and thus explicitely mentioning
the architectures would be a clean solution that would prevent us from
trouble in case the unstable -> testing propagation would become more
strictly as it is (obviousely) currently.
On the other hand I doubt that GNUmed is in real life used on those
architectures that show the missing depends (well, ia64 might be a problem -
is there really no OpenOffice available for this architecture???) and
even more importantly, if the packages become available at one day
(and I can not imagine that this could last even longer for ia64) the
GNUmed packages will have the right dependencies immediately without
a new upload. This might be a slight advantage over fixing the problem
as mentioned above.
What do you think?
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: