persistent clutter and ghc breakage

[Alex Lancaster]

>>>>> "PR" == Peter Robinson  writes:

>> There appear to be a boatload of broken deps for packages based on
>> clutter (presumably because of API bump from 0.9 to 1.0) that have
>> been listed here for over a week and no movement to fix most of them.

PR> It was actually broken on the move from 0.8 to 0.9 (and there were a
PR> couple of smaller api breakages during the 0.9 process).

>> Have the other apps been ported to the new API so they just need to be
>> built, or have they not yet been ported? (I tried to find an update
>> of cluttermm to 1.0 but only 0.9 versions are on the gnome site).

PR> No, they haven't in most cases been ported yet. All the pyclutter*
PR> stuff and cluttermm are still to be ported to the new API. The 0.9
PR> versions if they are available might/should compile against 1.0.

OK, thanks for the update.  I looked into the cluttermm, it seems that
cluttermm is already at 0.9.4 but doesn't seem to build against the
new clutter 1.0.x.  Given that so many packages haven't been ported,
it doesn't seem clear to my why clutter was updated to 0.9/1.0 in the
first place, however.  Since there seems to be no proper/regular
clutter maintainer (as you suggest below) who could co-ordinate these
things, this certainly contributes to the problem.

>> If the latter, it would be nice the maintainer of clutter did an
>> inventory of dependent-packages and co-ordinate with downstream
>> consumers of clutter to make sure that there was a plan to update
>> those packages, or built a compat- package if necessary. Otherwise
>> users of rawhide are left with huge swathe of breakage:

PR> [snip]

>> I must be a broken record on this, but it would be nice if maintainers
>> could make announcements to all concerned (e.g. on
>> fedora-devel-announce) about API/soname etc. bumps in major
>> libraries/frameworks *before* they are put into motion so that the
>> dependent packages can be rebuilt in a timely manner.  Or if that
>> causes too much breakage where, for example, many apps aren't ready to
>> be ported to the new version, then consider delaying the update for a
>> while or introducing compat- packages.

PR> No idea about the ghc stuff but until recently there wasn't really a
PR> owner to the clutter* stuff.

I looked into the ghc-* packages.  Seems there was some build system
problem that was probably transient that prevented the previous mass
rebuilds.  Seems that the versions bumped and tagged for the mass F12
rebuild now build properly.  I am kicking off new builds now, so
hopefully that will fix that breakage (although don't know why the
ghc-* package maintainers haven't chimed in with a rebuild attempt or
two as yet).

Alex