Bug#757241: libpeas, seed and FTBFS bugs.

peter green plugwash at p10link.net
Thu Sep 4 19:42:51 UTC 2014


I was looking at why gnome-core is not yet installable on arm64 
(currently checking with both debian-ports and debian official in 
sources.list). One of the problems I ran into was the depchain.

gnome-core->eog->libpeas->seed

Seed currently has four RC bugs, three of them are duplicates of each other and relate to failures on big endian architectures which does not appear to be getting much attention upstream and one general FTBFS bug that has a fix upstream (and has had for some time).

I have been informed that libpeas is already built without seed support on hurd-i386 mips powerpc s390x sparc and there are outstanding requests to add hppa and alpha support to that list ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757241 ). 

Looking at the seed packages with apt-cache rdepends I get

libseed-gtk3-0
Reverse Depends:
  libpeas-1.0-0
  seed
  libseed-gtk3-dev
  libpeas-1.0-0

libseed-gtk3-dev
Reverse Depends:
  gnome-core-devel

seed
Reverse Depends:

seed-doc
Reverse Depends:
  libseed-gtk3-dev

Build-rdeps shows a similar story with libpeas being the only source package in debian listed.

The dependency of gnome-core-devel on seed is also architecture qualified (as not mips) so presumablly seed is optional there too.

I see three possible ways to get things back to a sane (non rc-buggy) state

1: Fix all the FTBFS bugs in seed.
2: Apply the fix the general FTBFS in seed. Check what architectures the resulting package builds on and either fix or declare seed unssupportable on any remaining architectures. On the architectures where seed has been declared unsupportable adjust libpeas and gnome-core-devel to eliminate dependencies on it and then request removal of the old seed binaries from those architectures.
3: get rid of seed completely.

Option 1 would obviously be prefferable in an ideal world but it doesn't seem like there is anyone prepared to do the work 
Option 2 seems like the most sensible course of action to me.
Option 3 is probablly over-aggressive.



More information about the pkg-gnome-maintainers mailing list