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

isdnutils getting into testing is a problem...

There's a little problem with getting isdnutils into testing...
Finally, after more than a year after isdnutils was split up into more
logical parts, it's a valid candidate for installation, without anyone
filing an RC bug at the last moment. Now I'm wondering why it's not
going in anyway, and I discover in unstable_probs.html the following:

- Binaries from isdnutils 1:3.1pre1b-21 cannot be installed:
  - isdnlog-data(hppa)
  - isdnlog-data(hurd-i386)
  - isdnlog-data(m68k)
  - isdnlog-data(sh)

(aside: the ftp-master.debian.org/testing/ link with the excuses.html
etc. info available should be made more visible on the developers'
corner, it's not quite obvious that the link there gives all this info)

Anyway: The problem is that a couple of the packages generated from
isdnutils source are applicable for all architectures, and most are only
usable where certain (ISDN) hardware is supported by the linux kernel.
isdnlog-data falls under the second category, BUT it's data that's
architecture-independent.  It exists to supply isdnlog with knowledge of
area codes, costs etc. for calls logged by the system. So it's marked
architecture: any, and depends: isdnlog.

However: this means that it gets rejected for testing because this would
lead to isdnlog-data being available for e.g. hppa but its dependencies
cannot be satisfied.

I'm now hoping that there is some sort of override for this, so that
even though it's architecture: all, it won't get listed for the above
architectures. The only two alternatives I can see is to make it not
depend on isdnlog (meaning it could get installed on e.g. hppa, but
won't be of any possible use), or make it architecture: i386 alpha etc.
(meaning 800kB of data gets regenerated by every build daemon and that
data gets duplicated uselessly in the archives).  If I have to choose, I
choose the first, but I'm hoping there's an override possible.

Help! :-)

Paul Slootman

Attachment: pgpg7teNWw7yR.pgp
Description: PGP signature

Reply to: