On Fri, Mar 29, 2013 at 07:40:17PM +0000, Adam D. Barratt wrote: > It was already requested in #695201, where Julien raised some > concerns.
OK. Thanks for merging. On Wed, Dec 5, 2012 at 10:02:57PM +0800, Paul Wise wrote: >> What's causing the ABI change? Is it due to using a different >> fso-specs version than the one which was used to generate current >> libfso-glib? > Correct. > > > That would mean that we're not only not building from source, > > but we're also not actually shipping the source anywhere, and I > > don't think that should be ignored. > Hmm, ok. I see the following resolutions: 1. uploading an older fso-specs version to sid, which should avoid the API change. Let fso-specs migrate to wheezy and ignore the bug in libfso-glib. 2. uploading an older fso-specs version to sid, which should avoid the API change. Then fix the libfso-glib package. Then both should be able to migrate to testing. 3. use the new API, and binNMU all packages depending on it. 4. ignore everything for wheezy 5. remove the FSO/SHR stack from testing (libfso-glib is a reverse dependency for almost all components) Option 1 doesn't make much sense, since fixing the bug in libfso-glib should be easy with a matching fso-specs. I guess it's too late in the release process for option 3. Personally I would prefer solution 4. It's not like there is no source at all - upstream delivers libfso-glib with the pregenerated code. Previously this kind of code had been written by hand without the xml abstraction anyway. Option 5 is also a possibility. The FSO/SHR stack is not that popular. According to popcon there are 10 users. -- Sebastian
signature.asc
Description: Digital signature
