p-a-s/n-f-u: isdnutils and reverse-build-depends of libcapi20-dev

Lionel Elie Mamane lionel at mamane.lu
Sat Jan 27 09:46:10 CET 2007


I'd like to clarify the package-arch-specific / s390 not-for-us status
of isdnutils and of a few of my packages which build-depend on
libcapi20-dev, a binary package built by isdnutils.

* asterisk-chan-capi is in not-for-us for s390. Why? Reading old build
  logs suggests that the problem was that the build-depends on
  libcapi20-dev was not satisfiable on s390. It is now. So, unless you
  have another reason to have it as not-for-us, please remove that!

* capi4hylafax is architecture-restricted in p-a-s; the only reason
  known to me for that would be that it build-depends on an
  architecture-restricted package, namely libcapi20-dev. But the
  restriction is more strict than the actual situation in etch/sid;
  please include _all_ architectures that have or will have
  libcapi20-dev installed. That is, to the best of my knowledge:

  alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc

  Given that the only reason is unavailable build-depends, wouldn't
  state "dep-wait" be more accurate than a listing in p-a-s? At least
  then it doesn't need human intervention when the array of
  architectures the build-dependency is available on grows.

* p-a-s lists "chan-capi". This package has been removed from Debian:
  http://packages.qa.debian.org/c/chan-capi/news/20050322T042955Z.html
  You probably want to remove that line.

* p-a-s lists libcapi20 as being architecture-restricted; in
  particular s390 is not in the list. There are several issues here:

  1) The binary package is now named libcapi20-3, so I presume that
     this line has no effect. If the reason for existence of that line
     still exists, it should be changed to libcapi20-3. If not, remove
     it.

     On the other hand, it has been quite some time since the package
     was named libcapi, so even if theoretically justified, it seems
     that not having that line doesn't bother anyone... as nobody
     noticed.

  2) I would expect libcapi20-dev to have the same restrictions as
     libcapi20-3, but it is not present in p-a-s.

  3) s390 has successfully built libcapi20-3 and libcapi20-dev, and
     they are in the archive, probably as a result of the renaming not
     being reflected in p-a-s. So either these packages are broken,
     but nobody noticed because nobody used them or s390 should be
     added to the list. I'm inclined to believe that s390 should be
     added to the list because the "Architecture:" line of the control
     file in the sources includes s390.

     More generally, probably p-a-s should reflect the "Architecture:"
     lines; missing are hppa, ppc64, s390, for all binary packages of
     isdnutils (except arch: all ones).

     Note that hppa seems to be in the same situation than s390: the
     packages are successfully compiled and installed.

  4) The comment says:

     # isdnutils has one arch: any package (isdnvboxclient), so we can't % it ....

     but that is wrong. isdnvboxclient is:

     Architecture: alpha amd64 arm hppa i386 ia64 m68k mips mipsel powerpc ppc64 sparc s390

     like the rest of the binary packages (except for the architecture: all ones).

     So, % it all the way?

  5) Any particular reason armeb/armel is not in the list, both for
     p-a-s and the architecture line in debian/control?

-- 
Lionel



More information about the Pkg-voip-maintainers mailing list