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

Re: debian-med hint (debcheck results)



[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: